The lowercase 'x' following the username in /etc/passwd is where the encrypted password would normally be, and 'x' means the password is hidden in the shadow password file. It doesn't donate the graphical system for the user.
/bin/sh is "any bourne-compatible shell". If bash is started with this as argv[0], it starts in a special compatibility mode. It is similar to passing the --posix argument with special rules for startup files and argument handling. see "invocation" in the manual.
While most of what you said is good and fairly accurate, I do think you may be missing a subtle point regarding sh. When bash (Bourne again shell) is invoked using the sym link as sh, it causes the shell to run in POSIX compatible 'sh' mode i.e. the extensions, addiitoonal buil-ins and expanded syntax added by bash are disabled and the shell operates in 'sh' compatibility mode. This is quite important and useful. What it means is that any script you write with #!/bin/sh will run on any POSIX compatible (nix system). The script may still fail because it relies on other programs which are not installed or not the same, but it will not fail due to an error in the shell itself. For example, I could write a shell script which can run on Linux, BSD and macOS. So, if someone says they are running sh sehll, they may in fact be running sh (I think a 'real' sh still exists on BSD). This ability to run on different platforms can be very useful when you want to do things like simplify or automate build and install scripts for software which can be built for different platforms. For example, you could probably write a sh script to run git, configure, build and install emacs on Linux, BSD and macOS. Finally, you will still find real 'sh' shells on small systems - systems with tight resource constraints as it has a small footprint and uses both less disk and memory. Also note that 'bash' also supportes two different sets of init files, allowing you to have different configurations for when it is invoked as sh and when it is invoked as bash. SO /bin/sh and /bin/bash (or the more modern /usr/bin/sh /usr/bin/bash) are NOT the same and some people do actually run with sh as their shell.
Yea, I forgot that Debian and Ubuntu now link 'sh' to 'dash'. Good catch. I'm pretty sure that they use 'bash' as the root user's interactive shell still since it's just better for user interaction. They use 'dash' for executing POSIX shell scripts because it's a bit faster at that than 'bash'.
@@DistroTube Ah, interesting! I was actually surprised to see that it wasn't Bash ... I've a ridiculously long .bashrc and basically have vendor lockin 😬
When people say they use sh they refer to the Bourne shell. This is the shell you get in many docker base images for example (python3-alpine for instance does not have bash by default but you can use sh)
@@Techiesse Ah yes, I totally agree with your main point. Most people that say "sh" mean the Bourne shell. But I am not aware of any modern system that still has the original bourne shell. So in reality, when people say "sh" they mean Bourne shell, but actually refer to any modern implementation that is compatible with the old Bourne shell (be it dash, ash, ksh, bash in POSIX mode, etc)
Giiven that most most Linux distributions use Bash for their default users'/interactive shell, unless someone is using one of the BSDs or a very obscure Linux distro with odd defaults, if a user says they're using sh or /bin/sh, it's probably safe to assume that they're using bash. If they're using something else, then they probably changed it themselves and they won't be the ones unsure of which shell they're using. I tend to stick with the default, and in at least twenty years of using Linux, that has practically *always* been Bash.
I thought 'sh' originally referred to the Bourne shell? And... bash is the 'Bourne Again Shell'? But it is a distinct Unix/Linux shell... I don't think anyone one uses the Bourne shell any longer as it's been superseded by bash, but 'sh' is a distinct shell even though it only provides a subset of functionality relative to bash. For these reasons I suspect they just put in a link to bash on most modern Linux systems when you indicate you wish to log into the Bourne shell rather than providing an installation of the Bourne shell by default. Although I'm not sure you could find a way to install the Bourne shell on most modern Linux systems, in part because I don't think it's 'free' software'.
Cron uses sh. Which on debian based distros is dash. And really, whether cron defaults to sh or dash does not matter, because bash shorthand will not work in either. There are workarounds for sure, but it can be somewhat frustrating when code works just fine in user terminal but not when called from cron, because cron is using dash, not bash.
Im new to linux and recently started learning Bash. Did I make a good choice with it, or should've I started with another shell? I know it comes as a default to a lot of distros, hence I chose it. Still confused as to what is the difference between the differerent shells, though..
It's far from "the best ™", but it's the most common and basic shell - the one you will encounter in the wild. That makes it a good one to learn first.
@@kpcraftster6580 So what are the limitations of bash then? I've found none so far and started with Linux back in 1996 - except for "graphical pretties" that I don't need in a shell anyway, except for maybe a bit of colour highlighting to show file types or key words when I do an "ls" or "less".
@@terrydaktyllus1320 Bash lacks the speed of Zsh and Dash, the simplicity of Ksh, the extensibility of Zsh, and the user-friendliness of Fish, customized Zsh or even PowerShell.
@DistroTube can you do these complex nu shell queries, like, search the project directories and return the one with plenty of shell scripts? I'd love a video on that
What shell do you use? I use the symlink that points to whatever I set with chsh. LMAO I'd never truly troll someone who didn't know that though. There was a point in time not long ago I was asking about shell behavior in a terminal emulator irc channel. My brother in christ shell and terminal are two different layers entirely. 😁
@@terrydaktyllus1320 Indeed, so if you had to learn just one, then bash is the way to go. At least, if you plan on using multiple systems without having to first install your favorite shell each time.
I found that chsh -l did not work for me either (running LM). The only options I have are -h -R -s I wonder if there are different versions of chsh depending on the distro.
Ah, yes! I've run into this annoying issue on some Debian-based distros before. Their 'chsh' program is different. There is no "list" flag. But on every Linux distro, you should be able to simple 'cat /etc/shells' and get the available shells. I'm pretty sure that this is all 'chsh -l' is doing anyway.
@@DistroTube Thanks for the heads-up on this. The file /etc/shells is listed in the chsh man page, so I did cat that, as you recommended. Is there any way to install the Arco version of chsh onto LM (other that installing Arco 🤪 )?
The terminal is a program that provides a user interface; it's not a user interface itself. The shell is the user interface.....it's the command line interpreter.
@@terrydaktyllus1320 thank you. I shall try that. I've been a Linux user since the early days of Redhat (actually earlier than that but I don't recall what version it was prior to getting Redhat on my desktop at work. Everyone else was using Windows but I refused 😊
sh is a interpreter to scripts, you run file.sh and this have a sh bang, the terminal and the shell you are using is going to run sh to run that file, you can change sh to dash, is another sh interpreter but is a lot faster (that is what i hear from bsd and gentoo people a long time)
DT, don't state that sh is not a shell. Bourne shell (sh) is a shell. It is not installed in most Operating Systems. But a lot scripts use the follwing sheabang #!/bin/sh. So maintainers create a link in /usr/bin/sh to bash or dash.
Nice video .... unfortunately you never got around to telling us how to load a NEW or DIFFERENT shelll ....... maybe you need to start putting together a script ahead of time .....
I'm sorry DT, but what you are telling is not 100% correct. The shell "sh" is the Bourne Shell created by Stephen Bourne at Bell Labs. It started it in 1976 and was released in 1979 and was of course developed for Unix. The shell Bash means "Bourne AGAIN shell" and is a reimplementation of the Bourne Shell for the GNU Project and contained features of sh, csh and ksh. In fact sh, is the father of all these shells that you talk about. All sh scripts are compatible with bash, but bash has a lot more functionality. The reason that you see a link from sh to bash, is for compatibility. The syntax of all sh scripts is compatible with bash. Therefore, if you happen to get a script which was written for sh, it will work because it will be interpreted by bash. There is in fact an implementation of the former sh shell for Linux and it is called "Heirloom Bourne Shell", I don't know who may want to use it though!
Wrong about 'system shell'. System shell is the shell that the system uses, not root users shell. Though they may be the same shell. Should be dash on any Debian derivative. $ which sh should give /usr/bin/sh and $ file /usr/bin/sh should give /usr/bin/sh: symbolic link to dash if $ echo $SHELL does not give /bin/bash your shit is broken.
The lowercase 'x' following the username in /etc/passwd is where the encrypted password would normally be, and 'x' means the password is hidden in the shadow password file. It doesn't donate the graphical system for the user.
Noted. Thanks for the correction.
was gonna mention that as well
thank you for clearification! and dislike to DT for misinformation.
@@mort_brain he made an honest mistake and accepted the correction well.
Was furiously scrolling to the comments to mention that as well :)
bro finally learned from his days of setting sh to fish so proud
/bin/sh is "any bourne-compatible shell". If bash is started with this as argv[0], it starts in a special compatibility mode. It is similar to passing the --posix argument with special rules for startup files and argument handling. see "invocation" in the manual.
/bin/sh used to be the Bourne shell.
In the very old times that I sadly remember it was ;) sometimes also on minimal distributions. Perhaps on Slackware to this day.
It still is on BSDs. In fact sh is the default shell for root in FreeBSD.
Bourne Again SHell
@@krzysztofwaleska Slackware uses bash, if I remember correctly
@@krzysztofwaleska It's a symlink to bash. Though on any given system there's nothing to stop you from replacing it with whatever you want.
Awesome video. I love how it starts from a real confusion and goes from there
Is Vim makes you faster or not ?
@@Rudolfucius no I'm my twin brother
My favorite editor, and the best editor PERIOD, no arguements, is $EDITOR.
I think if you read the man page os bash. It will say when called as sh, it will run in sh compatability mode.
That explains a LOT
While most of what you said is good and fairly accurate, I do think you may be missing a subtle point regarding sh. When bash (Bourne again shell) is invoked using the sym link as sh, it causes the shell to run in POSIX compatible 'sh' mode i.e. the extensions, addiitoonal buil-ins and expanded syntax added by bash are disabled and the shell operates in 'sh' compatibility mode. This is quite important and useful. What it means is that any script you write with #!/bin/sh will run on any POSIX compatible (nix system). The script may still fail because it relies on other programs which are not installed or not the same, but it will not fail due to an error in the shell itself. For example, I could write a shell script which can run on Linux, BSD and macOS. So, if someone says they are running sh sehll, they may in fact be running sh (I think a 'real' sh still exists on BSD). This ability to run on different platforms can be very useful when you want to do things like simplify or automate build and install scripts for software which can be built for different platforms. For example, you could probably write a sh script to run git, configure, build and install emacs on Linux, BSD and macOS. Finally, you will still find real 'sh' shells on small systems - systems with tight resource constraints as it has a small footprint and uses both less disk and memory.
Also note that 'bash' also supportes two different sets of init files, allowing you to have different configurations for when it is invoked as sh and when it is invoked as bash. SO /bin/sh and /bin/bash (or the more modern /usr/bin/sh /usr/bin/bash) are NOT the same and some people do actually run with sh as their shell.
This is a valid point, and why I always explicitly use /bin/bash for the shebang when I write shell scripts.
You can view /etc/shells which also gives you a list of shells.
On Debian-based systems, looks like `sh` symlinks to `dash` (Tested on Debian, Mint, and Raspbian.).
Yea, I forgot that Debian and Ubuntu now link 'sh' to 'dash'. Good catch. I'm pretty sure that they use 'bash' as the root user's interactive shell still since it's just better for user interaction. They use 'dash' for executing POSIX shell scripts because it's a bit faster at that than 'bash'.
@@DistroTube exactly
@@DistroTube Ah, interesting! I was actually surprised to see that it wasn't Bash ... I've a ridiculously long .bashrc and basically have vendor lockin 😬
on void as well - /usr/bin/sh -> /usr/bin/dash
can confirm on ubuntu
When people say they use sh they refer to the Bourne shell.
This is the shell you get in many docker base images for example (python3-alpine for instance does not have bash by default but you can use sh)
I thought alpine used the very old school ‘ash’ shell?
Alpine uses busybox's fork of ash. In an alpine system /bin/sh is typically just a symlink to the busybox binary
@@gthar Ops. I think I gave a bad example mentioning python3-alpine.
First sentence still vaild tho.
@@Techiesse Ah yes, I totally agree with your main point. Most people that say "sh" mean the Bourne shell.
But I am not aware of any modern system that still has the original bourne shell. So in reality, when people say "sh" they mean Bourne shell, but actually refer to any modern implementation that is compatible with the old Bourne shell (be it dash, ash, ksh, bash in POSIX mode, etc)
Giiven that most most Linux distributions use Bash for their default users'/interactive shell, unless someone is using one of the BSDs or a very obscure Linux distro with odd defaults, if a user says they're using sh or /bin/sh, it's probably safe to assume that they're using bash. If they're using something else, then they probably changed it themselves and they won't be the ones unsure of which shell they're using.
I tend to stick with the default, and in at least twenty years of using Linux, that has practically *always* been Bash.
I thought 'sh' originally referred to the Bourne shell? And... bash is the 'Bourne Again Shell'? But it is a distinct Unix/Linux shell... I don't think anyone one uses the Bourne shell any longer as it's been superseded by bash, but 'sh' is a distinct shell even though it only provides a subset of functionality relative to bash. For these reasons I suspect they just put in a link to bash on most modern Linux systems when you indicate you wish to log into the Bourne shell rather than providing an installation of the Bourne shell by default. Although I'm not sure you could find a way to install the Bourne shell on most modern Linux systems, in part because I don't think it's 'free' software'.
Alpine uses sh
I use GNOME shell personally.
I use bash. Nothing more, nothing less.
Couple days ago, I've run chsh, set fish as my login shell and... break login in Wayland sessions 😂
Hey DT, @DistroTube Are you a Shell that your spirit uses to interact with the world? What do you think?
Maybe you were talking to someone who works on unix. The bourne shell sh is still used on hp-ux and solaris.
She sells sea shells on the sea shore
She sells Csh on the C#
Cron uses sh. Which on debian based distros is dash. And really, whether cron defaults to sh or dash does not matter, because bash shorthand will not work in either. There are workarounds for sure, but it can be somewhat frustrating when code works just fine in user terminal but not when called from cron, because cron is using dash, not bash.
I love to use the fish shell :)
I prefer dash for scripts simply because it's posix. It took me a long time to get all the bashism I used out of my head. But boy do I miss arrays.
And POSIX compliance is important to you because?
@@exnihilonihilfit6316 Sheer boredom.
@@exnihilonihilfit6316Portability? Not everything has BASH, nor should it
@@exnihilonihilfit6316 portability
(and it runs faster)
@@anon8510 Learned most C,C++ a web web languages. Been putting off python because F python.
No -l for Kubuntu. Any other utils to list shells?
cat /etc/shells -- it's the same info
Im new to linux and recently started learning Bash. Did I make a good choice with it, or should've I started with another shell? I know it comes as a default to a lot of distros, hence I chose it. Still confused as to what is the difference between the differerent shells, though..
Learn bash
It's far from "the best ™", but it's the most common and basic shell - the one you will encounter in the wild. That makes it a good one to learn first.
SH for scripting is more intuitive than bash, even if it has some limitations, scripts written in sh can be runned on every *unix-like machine.
@@kpcraftster6580 So what are the limitations of bash then? I've found none so far and started with Linux back in 1996 - except for "graphical pretties" that I don't need in a shell anyway, except for maybe a bit of colour highlighting to show file types or key words when I do an "ls" or "less".
@@terrydaktyllus1320
Bash lacks the speed of Zsh and Dash, the simplicity of Ksh, the extensibility of Zsh, and the user-friendliness of Fish, customized Zsh or even PowerShell.
Have you tried using powershell as the default shell ? 😀
No, but I have tried using 'nu' shell as my primary shell before. It's got some powershell-like features to it. Try it out.
@@DistroTube did you do a video on nushell before? i dont quite remember
@DistroTube can you do these complex nu shell queries, like, search the project directories and return the one with plenty of shell scripts? I'd love a video on that
Very good and very nice! Thank you!
... some folks also mistakenly call /usr/ USER ....
😉
*Immediately sed replaces all old scripts that have #!/bin/sh => #!/bin/bash*
🤫 Shhh, you saw NOTHING!
So sh is the sysvinit of "shells"?
I like it even more now
I tried out qbsh, but was disappointed with how unlike QBasic it was. I'm thinking about writing my own version.
What shell do you use? I use the symlink that points to whatever I set with chsh. LMAO I'd never truly troll someone who didn't know that though. There was a point in time not long ago I was asking about shell behavior in a terminal emulator irc channel. My brother in christ shell and terminal are two different layers entirely. 😁
Wasn't the original Bourne shell just sh?
Oops, Thompson and Mashey shells were first.
Zsh can be made good with extensions and customization.
But Fish is good out of the box.
And PowerShell somehow still has better syntax than Bash.
But bash is on every single Linux system that there is - "learn once, use everywhere".
@@terrydaktyllus1320 Indeed, so if you had to learn just one, then bash is the way to go. At least, if you plan on using multiple systems without having to first install your favorite shell each time.
chsh -l don't work. I will stick to using dash.
I found that chsh -l did not work for me either (running LM). The only options I have are -h -R -s
I wonder if there are different versions of chsh depending on the distro.
Ah, yes! I've run into this annoying issue on some Debian-based distros before. Their 'chsh' program is different. There is no "list" flag. But on every Linux distro, you should be able to simple 'cat /etc/shells' and get the available shells. I'm pretty sure that this is all 'chsh -l' is doing anyway.
@@DistroTube Thanks for the heads-up on this.
The file /etc/shells is listed in the chsh man page, so I did cat that, as you recommended. Is there any way to install the Arco version of chsh onto LM (other that installing Arco 🤪 )?
@@Not-THAT-ChrisPratt Do you have no work to do or life to live...? Ugh.
Meanwhile, people actually running the Bourne Shell...
Learned something new today. Thanks DT
I thought the shell was the CLI (command line interface), otherwise known as the terminal.
That's incorrect - do "echo $SHELL" then "echo $TERM" at the CLI and notice the difference.
The terminal is a program that provides a user interface; it's not a user interface itself. The shell is the user interface.....it's the command line interpreter.
@@terrydaktyllus1320 thank you. I shall try that. I've been a Linux user since the early days of Redhat (actually earlier than that but I don't recall what version it was prior to getting Redhat on my desktop at work. Everyone else was using Windows but I refused 😊
Just to make a pedantic distinction: Y'all are talking about terminal *emulators* 😉
@@DistroTube thanks. I always learn something from your vids!
I use whatever is the default. Mostly Bash.
Thank you again, DT, for another insightful video.
This is exactly why I point ppl to your YT channel when they ask about learning Linux.
i am using the frog _shell ........ welcome to my pond ......
TIL. I thought she was the basic posix shell
I prefer a 105mm HEAT round myself.
Nushell
Shells & cheese
sh is a interpreter to scripts, you run file.sh and this have a sh bang, the terminal and the shell you are using is going to run sh to run that file, you can change sh to dash, is another sh interpreter but is a lot faster (that is what i hear from bsd and gentoo people a long time)
clicked like before hearing a word.
(especially so recently after immolo started doing some fun chsh calamity videos).
Never seen anyone confused about this, but they need to be kindly advised to read the manual
'Kindly' lol ... krtfm
@@halfsourlizard9319 kindly read the friendly manual
@@halfsourlizard9319 I wrote 'kindly read the friendly manual' as a response to you but that got removed. Too polite for RUclips?
@@oalfodr Big tech censoring friendliness to try to devolve everyone into hateful trolls!
@@oalfodr let me try this: read the FFFAT manual
DT, don't state that sh is not a shell. Bourne shell (sh) is a shell. It is not installed in most Operating Systems. But a lot scripts use the follwing sheabang #!/bin/sh. So maintainers create a link in /usr/bin/sh to bash or dash.
Just like the "I have the oldest xbox known to man" video, "everyone has /bin/sh, it came free with your f-ing Linux"
1. I like that I got the answer I was looking for in the first minute
2. I got to be this video's 666th like
Nice video .... unfortunately you never got around to telling us how to load a NEW or DIFFERENT shelll ....... maybe you need to start putting together a script ahead of time .....
I'm sorry DT, but what you are telling is not 100% correct. The shell "sh" is the Bourne Shell created by Stephen Bourne at Bell Labs. It started it in 1976 and was released in 1979 and was of course developed for Unix. The shell Bash means "Bourne AGAIN shell" and is a reimplementation of the Bourne Shell for the GNU Project and contained features of sh, csh and ksh. In fact sh, is the father of all these shells that you talk about. All sh scripts are compatible with bash, but bash has a lot more functionality. The reason that you see a link from sh to bash, is for compatibility. The syntax of all sh scripts is compatible with bash. Therefore, if you happen to get a script which was written for sh, it will work because it will be interpreted by bash. There is in fact an implementation of the former sh shell for Linux and it is called "Heirloom Bourne Shell", I don't know who may want to use it though!
What are all those numbers in the shell 🔢
Or rather I mean, Why 🤔
Wrong about 'system shell'.
System shell is the shell that the system uses, not root users shell. Though they may be the same shell.
Should be dash on any Debian derivative.
$ which sh
should give
/usr/bin/sh
and
$ file /usr/bin/sh
should give
/usr/bin/sh: symbolic link to dash
if
$ echo $SHELL
does not give
/bin/bash
your shit is broken.