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.
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'.
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)
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 🤪 )?
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.
@@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.
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.
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)
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.
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 😬
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.
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.
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. 😁
@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
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.
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 😊