 Don't get it twisted. POSIX compliant shell and bash are not the same thing. A lot of people ask me to do more bash scripting tutorials. But the fact is I actually don't really write bash scripts. It very rarely do. When I write scripts, I nearly always make them narrow shell scripts. And bash is technically something a little different. So to be clear, here I am running bash if you can echo 0 and see whatever you're running in your command line. And of course most commands you run if I'm just running echo commands or something like that. They're going to be the same whether you're running in the classical Unix shell or in bash. But there are differences. They are very important. And if you want to write scripts that run fast and are portable, I recommend against using bash for most cases. Now to be clear, if you go to my GitHub, I'll have dozens of scripts. Nearly all of them are POSIX compliant shell scripts. There are a couple bash scripts I have. So I'm going to explain why. I'm going to show you some of the cool things that bash can do that separate it from other scripts. But I importantly want you to be aware that there is a difference. And it is important to know that difference. Okay, so for most things, as I said, most basic commands are going to be the same in POSIX compliant shell and bash. But there are a couple things that are different. Let me give you some examples. So one, I'm going to run the command packman queue. This, of course, is an Arch Linux command. But it lists out all of the programs I have installed on my computer. So I can take this as an example. Let's output that to a file, progs1. In fact, I'll take that file, progs1. And I'm going to copy it to progs2. Now I'm going to open up that second file. And I'm just going to delete a couple lines. Not too many. I'll just delete a couple lines. Now, I do this because you may know you can run this command diff on two different files. I'm going to give it progs1 and progs2. And diff will print out all the lines that are different. So in this case, it's showing us that these red lines with the greater or less than sign, these are all present in the first file but not the second. So this, of course, is exactly the same. Diff is the same in any kind of circumstance. You can run this command in POSIX compliant shell and bash. It's not the commands that are different. It's the syntax that's different. And one nice thing about bash that is not present in POSIX compliant shell is let's say I delete progs1. Now, as we said a second ago, progs1 is really just the output of pacmanq. So one thing we can do is instead of saying progs1 here since we deleted that file, we can actually say pacmanq and put it in parentheses with the less than sign before. Now, this is called process substitution. And process substitution is a bashism. Now, if I run this, you'll see that it looks basically the same as when we had an independent file. And what it's doing in this circumstance is that it's comparing not two files but a file with the output of a command. It's checking to see what's different about them. Or we could compare two different commands as well. So I could say something like pacmanqn which lists all the local packages. So now it's going to list out all the remote or the AUR packages. So we can run that just as well. Either way, this is process substitution and this is a bashism. So why is this important? First off, there are some shells which will deliberately try not to have bashisms. They'll try to be narrowly posix compliant. And MKSH is one of them. So if we run the same command, if we run diff and then pacmanq, compare that with pacmanqn, if we run that it's going to give us an error, syntax error, unexpected parenthesis. Actually, let me make that a little bigger. This is because MKSH doesn't have bashisms. It tries to be narrowly posix compliant. Now why is this important? So the thing to remember is that bash is very nice as an interactive shell. It has all these cool features. You can have a bash RC and all these bash profiles and stuff like that and all this stuff all over the place. Now MKSH can have some of those things but bash also has this additional syntax. And bash runs very slowly. It is one of the slowest shells out there. Again, it's nearly default on every machine but in terms of actually running scripts, it's very slow. So if you run this command, you can run this on your machine right now, LSL, BNSH. Now depending on, this will be different for different distributions but if you actually go to your BNSH file, you'll find that there is not actually a file called BNSH. It actually is just a link that links to another program. On my machine I have a link to dash. Dash like MKSH is a narrowly posix compliant shell. And the reason I have this is because if I link BNSH to dash, things are going to run much faster. All the scripts that are posix compliant shell scripts, they're going to run much, much faster with dash than they would with bash. But on Arch Linux by default, BNSH links to bash. So whenever Arch Linux finds a shell script that is not marked for bash, but I mean it is going to run bash scripts as bash scripts, but it's also going to run shell scripts as bash scripts because when you find BNSH, it's going to be linked to bash by default on Arch. So that means if you have a system that's running a whole bunch of shell scripts in the background or daemons or something like that, you're going to have a little more, running bash things are going to be a little slower, a little less snappy. Probably not even noticeable, but you know all that kind of stuff can add up. So it's usually a good habit. Dash of course you have to install. I don't think it comes default. I think it is actually default on Ubuntu or Debian or something like that. But on Arch Linux you'd have to install it and then link BNSH to it. It says it on the Arch wiki if you want to know how to do it. So it's usually a good practice. If you want a system that runs as fast as it can go I guess, it's usually a good habit to link your shell to something that's POSIX compliant rather than bash. Now that causes some complications for people who don't know any better I guess. Now let me go to my scripts folder. If I just go around in here, let me just open up some random scripts here. You will actually see that most of them are marked for BNSH. In fact the only two I have, this script here Cable, and there's another one called Shortcuts. I think that's in the Tools directory, but pretty much everything else is in BNSH. I deliberately try not to use bashisms in any circumstance in my scripts. So I'll mark them all as just being shell scripts and this will tell your system to run them as whatever your BNSH is, which again in my case is Dash. So why this can cause problems, a lot of times I will see I guess more novice users, they have just seen people use BNSH all the time and they will write a bash script with a bunch of bashisms in it. They might include something like Diff, Pacman Queue and then File. And if they include that in this file it will break if you have linked your shell to Dash, which again many distributions do by default and many people will do anyway. So be sure you know what is a bashism and what isn't. So I'll give you a couple other examples and then I'll show you a program that does it automatically. Just one thing that actually sort of annoys, so one thing if you want to compare, let's say I want to compare my browser, see what that is, if my browser is equal to Firefox. Then echo, you know, it's Firefox. So you'll see that nothing ran because my browser is not actually Firefox. I think my browser right now is surf. So okay well it's surf, I forgot to rename it. So this is how you compute whether something is equal to another thing in POSIX compliant shell. But a lot of bash users will want to do this thing where there are two brackets and two equal signs which technically is something different in bash that enables like glob matching and stuff. If you want to do glob matching in POSIX shell the easiest way to do it is actually with a case statement. But there are a bunch of features which again this might be nice because I think you could have some kind of regular expression here in bash but you can't do exactly the same in POSIX compliant shell. Okay, now most things that bash adds I think are just minor things like that that can easily be done in, you know, you can just rewrite it in typical shell and it's not a big problem. But there are a couple of things. Let me actually show you one, I've talked about this script before on my channel but it's one of my only other bash scripts and this uses enormous amounts of process substitution and stuff like that. I actually output, I output the output of T to an awk command and that goes to, you know, multiple different places and this is one of those circumstances where the innovations of bash are just such that I really just want to use it. You know, writing this kind of stuff in POSIX compliant shell would be a big pain. But anyway, so I just wanted to, hopefully this sort of clarifies things but to be clear, if you want some takeaways from this I recommend setting your SH to dash or something like that or some other POSIX compliant shell. It will make things run a little bit more snappy, a little less overhead and whenever you write scripts just be mindful whether they're bash or not bash. Actually, I should show you how to tell the difference if you don't know the difference. So there is a program that I have installed called ShellCheck. Okay, and I'll, let me actually go to this directory. So again, this file I have open over here, Shortcuts. So I can run ShellCheck on Shortcuts and nothing's going to pop up because there's no problem. ShellCheck actually checks for a lot of things. It'll check for like bad syntax or errors or non-recommended syntax but let's say I change this to just an SH file and I run ShellCheck on that. It's going to give me all these different errors because it detects, okay, well he wanted a POSIX compliant shell script but he has all of these different bash-isms here. So it will actually print out all the errors and ShellCheck is really nice if you don't have a good sense of what is a bash-ism and what isn't. So I recommend using that. I actually use it a lot and again it does more than just checking to see if it's POSIX compliant. It checks for other errors as well. So sometimes I'll run stuff through ShellCheck. But anyway, so I think that's about it for this video. I'll just, again, I recommend, just know the difference between bash-isms and normal shell and you'll probably be fine. Actually before I forget I'm going to put bash back in there because I'm going to quit the video and then forget about it. Anyway, that's about it and I will see you guys next time.