Done a quick scrub through the video and I'll have to get back to this video for a brush up on bash scripting as I want to update my bash scripts for adding interactive conditions for installing packages. For now I'll be liking it and adding to my Watch later playlist. Thanks
Follow up to the if statements explain why you almost never need to use a if statement, just use logical operatiors && || ; Good video i do hope you continue this series all the way up to very advanced bash scripting if your able to.
Thank you for this video. I am totally new to scripting. Honestly didn’t understand much. This got me started though had initial hiccups due to the spaces in variables or the lack thereof. Could you also do one on the scripting in fish shell and also highlight the difference between these two shell scripts
Any script that is executable but not in a executable path or known executable directory, needs the path in front of the name, in this case it was in the same folder (.) = current folder (/) = something in that folder so you just telling the OS run this script in the current directory, DT could have typed '/home/DT/bash-examples/script-name.sh' but of course for time and ease if your in the current folder as the script you want to run './filename.sh'. find all you OS executable paths type 'echo $PATH'.
You should do a short showing people how to make a function in the top three major shells to combine mkdir and cd into mkcd so that from then on you can just use that in the videos and point to the short for anyone confused by it.
Nice idea for a series of Bash script tuts. Perhaps next you can cover the CASE statement as an alternative to IF/ELSE. CASE is actually faster than IF/ELSE but in simple scripts, it will make very little if any difference.
What got me when i started with bash scripting is that spaces are not allowed when defining a variable . so string = "something" does not work (due to the spaces around the =). Hope it helps someone. otherwise great video. thanks !!
@@tatsutakamaro The High Precision Event Timer (HPET) hardware follows a specification by Intel and Microsoft, revision 1. HPET devices can support two interrupt routing modes. In one mode, the comparators are additional interrupt sources with no particular system role. Many x86 BIOS writers don’t route HPET interrupts at all, which prevents use of that mode. They support the other “legacy replacement” mode where the first two comparators block interrupts from 8254 timers and from the RTC. HPET is out of my information zone. they do have Linux versions with driver downloads, but i can not give you a good safe answer. From what i have read most of it deals with the BIOS in witch case i would assume C language is going to help a lot more then bash will. But again i dont know anything about HPET. And since the first line of the article i read included Microsoft and not Unix i feel it's more a Windows thing.
@@tatsutakamaro Looks like Linux uses something called the clockgettime as #include int main() { timespec ts; // clock_gettime(CLOCK_MONOTONIC, &ts); // Works on FreeBSD clock_gettime(CLOCK_REALTIME, &ts); // Works on Linux }means to measure the time is milaseconds
Nice, I made a interactive menu that was close to your last script. Just to do updates or find system info in a terminal. (with only arrows and no keyboard). Witch is next operators, boleans and escape sequences? :D
interesting topic. thanks for this. is it needed to make it executable with chmod? bash FILE.SH also seems to work. or is it that once its executable, it can be run anytime going forward with just typing FILE.SH. also if i remembered correct SH FILE.SH also executes it. BTW is used chatGPT to make a stopwatch script, so damn cool.
Yes i do think, you can leave it without exe permissions but that is really not the correct way to run scripts in a linux system, and is likely to throw errors. SH is just a different type of shell just as fish and zsh are to bash so is sh
Either is acceptable, but `./script.sh` is easier than `bash script.sh`, and you can even use different languages for scripts and point the shebang to that runtime, such as a Python program that you wish to execute from the terminal.
Can we bind keys in bash. Using keyboard hook and catching the pressed key or combination, and then sending it to the system as other keys? For ex, i press "a" but see "b" on the screen in any (or specified) application.
You believe bash is more complicated then python? I do not think so maybe if you learned python first and then bash, but even then python has so much more stuff to remember. I cant wrap my head around python yet it is hard to learn.
@@adamhamilton10 any script that is going to pass the 20 line limit, is MUCH better done in a proper interpreted programming language like python, ruby, perl, lua etc. than a shell program (bash, sh, zsh, etc). they are good for small scripts, not for scripts that are going to scale in complexity.
Actually, that's not entirely fair. Python itself isn't inherently bad but I routinely see an actual ton of really poorly written Python scripts from tons of inexperienced programmers. As an old coworker of mine once put it; "I had to unlearn 8 years of UCLA to make myself stupid enough to understand Python"
fun fact: I use ZSH for the interactive shell but 95% of my scripts are #!/bin/bash the rest are #!/bin/sh and a handful of assorted Ruby, Python and compiled C++ helpers
Better off sticking to POSIX compliant shell scripts and stay away from Bashisms to make your scripts more portable. Also, no need to actually run the shell just to code a script for it. If your using Fish, it's perfectly fine to start your editor in that shell and script for Bash.
@@NugentFan Doesn't matter most of the time for the small scripts I need to write to automate my work. Like, Python 3 was released in 2008. Python 2 was still used for quite a few years after that. Plenty of time to update. And for something with the complexity of a Bash script, it's not gonna be using too much advanced features in Python that require a very different syntax to migrate. For small syntax changes (like print in Python 2 vs Python 3), there was a script for that.
@@tengun I never liked Python. Bash script feels better. It is very good that you know your script cannot be run anywhere else except Linux But when you spend a lot of time and write a Python script and someone runs it on Windows or Mac with a little change, it is disappointing
@@NugentFan Python is actually better for that if you don't call system commands directly via os.system. The native library already accounts for the difference in the running operating systems. Bash script may have compatibility issue when running on different shells (zsh vs bash vs sh...) unless you're doing conditional branching that checks for which type of shell you're running on; or just forfeit the more advanced bash feature and opt for the less convenient way to write so that it can be supported on more systems. For me, I don't need my script to run on all systems because they're specifically designed for certain uses on certain systems only. Python is good enough for that and saves me a lot of time compared to racking my brain on how to write it in bash. I once wrote a dotfiles project that used bash to make backup, setup, and some other stuffs. Didn't work well on all systems when I needed it (because I sux at writing bash scripts for multiple systems). I ended up just using Python and it was much simpler (unless the system don't have Python installed)
@@tengun interesting. I had no idea that such a thing was possible. Yes, Python and its libraries are not usually installed. Maybe you can install the prerequisite programs in some way before running the script. Or, for example, you can use methods that include Python with your script, such as Docker, AppImage, or PyInstaller
Dude just goes right into it, like a bull in a china shop. Dude, bash isn't located in the same place for everyone. The very first thing you should teach people is to how to find where their bash is. Folks, type: _which bash_ in the terminal to see where your bash is located. Then use that path in your shebang statement.
you dont need to put double quotes .... unless you want to escape something " something" this is why i dont learn to code from youtubers, they only try to get some clicks
If you make a habit of it then you don't have to think about it. Spaces are especially annoying and if you've already added a " then it's simple to use one at the end and double quotes still allow you to expand shell variables and do command substitution.
We want more bash videos ❤🔥
I was thinking about first learning how to program in Bash, and you just uploaded a video about it, amazing
Thank you, DT!
Finally
I'm waiting for you to create a updated video to teach us precious scripting like forever
Love your Tuition videos. Please do more.
Great concept for a video series, bro. Would be a cool Patreon tier too.
Brilliant, great!!! Please do MOREEE!!!❤❤❤🎉🎉🎉
Need more daily usage examples as with choise
Thanks a mill DT😉
Thank you!!! I would love more like this.
Amazing vid bro, learned a lot ❤🐧
Done a quick scrub through the video and I'll have to get back to this video for a brush up on bash scripting as I want to update my bash scripts for adding interactive conditions for installing packages. For now I'll be liking it and adding to my Watch later playlist. Thanks
Follow up to the if statements explain why you almost never need to use a if statement, just use logical operatiors && || ; Good video i do hope you continue this series all the way up to very advanced bash scripting if your able to.
Good stuff 👍
great video
Thank you for this video. I am totally new to scripting. Honestly didn’t understand much. This got me started though had initial hiccups due to the spaces in variables or the lack thereof. Could you also do one on the scripting in fish shell and also highlight the difference between these two shell scripts
5:00 - why do you use './' in front of the script name if we're already in the needed directory?
Check out: th-cam.com/video/wBmJ7MH0xAU/w-d-xo.html
Any script that is executable but not in a executable path or known executable directory, needs the path in front of the name, in this case it was in the same folder (.) = current folder (/) = something in that folder so you just telling the OS run this script in the current directory, DT could have typed '/home/DT/bash-examples/script-name.sh' but of course for time and ease if your in the current folder as the script you want to run './filename.sh'. find all you OS executable paths type 'echo $PATH'.
@@DistroTube thanx a lot!
@@adamhamilton10 thanks indeed
You should do a short showing people how to make a function in the top three major shells to combine mkdir and cd into mkcd so that from then on you can just use that in the videos and point to the short for anyone confused by it.
it always confused me that neither offer that option
@@XenHat You would think every shell would've added it to the toolkit.
Nice idea for a series of Bash script tuts.
Perhaps next you can cover the CASE statement as an alternative to IF/ELSE.
CASE is actually faster than IF/ELSE but in simple scripts, it will make very little if any difference.
What got me when i started with bash scripting is that spaces are not allowed when defining a variable . so string = "something" does not work (due to the spaces around the =). Hope it helps someone. otherwise great video. thanks !!
thanks homie, more bash videos please, network chuck not delivering.
Can you really do everything you might imagine with Bash? What about working with memory or High precision timer (hpet)?
If it is a Linux command that bash can interpret, then yes.
@adamhamilton10 Sounds recursive: "can i do that in bash - yes, if bash has a command for that" - well, has bash got commands to work with hpet then?
@@tatsutakamaro The High Precision Event Timer (HPET) hardware follows a specification by Intel and Microsoft, revision 1. HPET devices can support two interrupt routing modes. In one mode, the comparators are additional interrupt sources with no particular system role. Many x86 BIOS writers don’t route HPET interrupts at all, which prevents use of that mode. They support the other “legacy replacement” mode where the first two comparators block interrupts from 8254 timers and from the RTC. HPET is out of my information zone. they do have Linux versions with driver downloads, but i can not give you a good safe answer. From what i have read most of it deals with the BIOS in witch case i would assume C language is going to help a lot more then bash will. But again i dont know anything about HPET. And since the first line of the article i read included Microsoft and not Unix i feel it's more a Windows thing.
@@tatsutakamaro Looks like Linux uses something called the clockgettime as #include
int main()
{
timespec ts;
// clock_gettime(CLOCK_MONOTONIC, &ts); // Works on FreeBSD
clock_gettime(CLOCK_REALTIME, &ts); // Works on Linux
}means to measure the time is milaseconds
@@adamhamilton10 thank you, I'll have a look in docs
Nice, I made a interactive menu that was close to your last script. Just to do updates or find system info in a terminal. (with only arrows and no keyboard). Witch is next operators, boleans and escape sequences? :D
interesting topic. thanks for this. is it needed to make it executable with chmod? bash FILE.SH also seems to work. or is it that once its executable, it can be run anytime going forward with just typing FILE.SH. also if i remembered correct SH FILE.SH also executes it. BTW is used chatGPT to make a stopwatch script, so damn cool.
Yes i do think, you can leave it without exe permissions but that is really not the correct way to run scripts in a linux system, and is likely to throw errors. SH is just a different type of shell just as fish and zsh are to bash so is sh
@@adamhamilton10 got it
Either is acceptable, but `./script.sh` is easier than `bash script.sh`, and you can even use different languages for scripts and point the shebang to that runtime, such as a Python program that you wish to execute from the terminal.
Damn your theme is beautiful
Nice video, congrats! However I’d like to make a suggestion: you failed to explain why you had to wrap stuff in brackets and parentheses…
Thanks for this! I hope it leads to more bash tutorials. Is ending a bash script with 'exit 0' overkill? Just wondering.
id say so. i use exit 1 instead. that way if im running it from a tty, i dont get logged out when the script terminates
Have to go back and look at your VIM, videos mine doesn't look like yours. so used Nano
Can we bind keys in bash. Using keyboard hook and catching the pressed key or combination, and then sending it to the system as other keys? For ex, i press "a" but see "b" on the screen in any (or specified) application.
Yes. You can also bind things like readline commands.
@anon_y_mousse that's a good news
Is it the .sh what tells it that it is a Shell Script, or is it the shabang?
Since this video is about bash scripting and not about bash as an interactive shell, it was not actually necessary to leave the fish command line.
bash syntax is so complicated... I use python whenever I can.
You believe bash is more complicated then python? I do not think so maybe if you learned python first and then bash, but even then python has so much more stuff to remember. I cant wrap my head around python yet it is hard to learn.
@@adamhamilton10 It's more about the syntax. For instance I find loops and conditionals to be much harder to remember in bash than in python.
@@adamhamilton10
any script that is going to pass the 20 line limit, is MUCH better done in a proper interpreted programming language like python, ruby, perl, lua etc. than a shell program (bash, sh, zsh, etc). they are good for small scripts, not for scripts that are going to scale in complexity.
Python is garbage for the most part. I said it
Actually, that's not entirely fair. Python itself isn't inherently bad but I routinely see an actual ton of really poorly written Python scripts from tons of inexperienced programmers. As an old coworker of mine once put it; "I had to unlearn 8 years of UCLA to make myself stupid enough to understand Python"
fun fact: I use ZSH for the interactive shell but 95% of my scripts are #!/bin/bash the rest are #!/bin/sh and a handful of assorted Ruby, Python and compiled C++ helpers
"I'm gonna make them choose 1, 2 or 3. Anything else I will force to 4"
You been taking lessons from M$ haven't you? 😉
you don't need sudo to run chsh for your own user just do chsh -s shell
Great accent
I don't like bash scripts. Too iffi.
Well done
Care to explain?
@@Teknishun if statements in bash start with if and end with fi.
270
Better off sticking to POSIX compliant shell scripts and stay away from Bashisms to make your scripts more portable. Also, no need to actually run the shell just to code a script for it. If your using Fish, it's perfectly fine to start your editor in that shell and script for Bash.
If we are using for our personal use then there is no problem sticking to non posix i guess
I just use Python
and when new version of python release your apps not work anymore.. like frets on fire that not work anymore!
@@NugentFan Doesn't matter most of the time for the small scripts I need to write to automate my work.
Like, Python 3 was released in 2008. Python 2 was still used for quite a few years after that. Plenty of time to update.
And for something with the complexity of a Bash script, it's not gonna be using too much advanced features in Python that require a very different syntax to migrate. For small syntax changes (like print in Python 2 vs Python 3), there was a script for that.
@@tengun I never liked Python.
Bash script feels better.
It is very good that you know your script cannot be run anywhere else except Linux
But when you spend a lot of time and write a Python script and someone runs it on Windows or Mac with a little change, it is disappointing
@@NugentFan Python is actually better for that if you don't call system commands directly via os.system. The native library already accounts for the difference in the running operating systems. Bash script may have compatibility issue when running on different shells (zsh vs bash vs sh...) unless you're doing conditional branching that checks for which type of shell you're running on; or just forfeit the more advanced bash feature and opt for the less convenient way to write so that it can be supported on more systems.
For me, I don't need my script to run on all systems because they're specifically designed for certain uses on certain systems only. Python is good enough for that and saves me a lot of time compared to racking my brain on how to write it in bash.
I once wrote a dotfiles project that used bash to make backup, setup, and some other stuffs. Didn't work well on all systems when I needed it (because I sux at writing bash scripts for multiple systems). I ended up just using Python and it was much simpler (unless the system don't have Python installed)
@@tengun interesting. I had no idea that such a thing was possible.
Yes, Python and its libraries are not usually installed.
Maybe you can install the prerequisite programs in some way before running the script.
Or, for example, you can use methods that include Python with your script, such as Docker, AppImage, or PyInstaller
Dude just goes right into it, like a bull in a china shop. Dude, bash isn't located in the same place for everyone. The very first thing you should teach people is to how to find where their bash is.
Folks, type: _which bash_ in the terminal to see where your bash is located. Then use that path in your shebang statement.
Shell.. not shill. Sigh
you dont need to put double quotes .... unless you want to escape something "
something"
this is why i dont learn to code from youtubers, they only try to get some clicks
If you make a habit of it then you don't have to think about it. Spaces are especially annoying and if you've already added a " then it's simple to use one at the end and double quotes still allow you to expand shell variables and do command substitution.
I methodically use curly brackets around my variables. slower? yes. safer? YES
Thank you!!! I would love more like this.