Hacker News Reader

Comment by chasil | Hacker News Reader

It is a very kind gesture to make this book freely-available.

It does have a small problem in the number of "bashisms" that it quietly promotes.

The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there.

It would be helpful to have a book that is clear that the POSIX.2 shell is not Bash.

View on HN

> It would be helpful to have a book that is clear that the POSIX.2 shell is not Bash.

Maybe the one thing I love about Linux culture (compared to the BSDs, illumos, etc.) is that it generally doesn't require everyone to adhere to some high UNIX religion.

Writing a shell script of more than 50 lines is hard to do correctly. Bash sometimes makes that a little easier. And it's almost ubiquitous. Forcing new Linux users to learn a POSIX compliant shell, when they are only likely to be using Linux and bash, is simply cruel and unusual. Just as including only `vi` in the base system instead of `nano` is a silly self-own.

I see this unreflective question far too often: "Why aren't people using my system and using Linux instead?" And the answer is pretty simple, Linux at least made efforts to reach out to people where they were, in hundreds of low effort ways, whereas your system probably didn't.

"Everyone should be using Linux" and/or "should love the command line" is pretty silly, but just as silly is "people should learn the POSIX shell" first. A shell they are likely never to use interactively. Because of a hypothetical portability concern? It's nuts.

just as silly is "people should learn the POSIX shell" first

Where did the GP make that assertion? I don't see anywhere in the post where they say "please rewrite all the shell examples in POSIX-compliant sh". All I see is a request to inform the reader that not every shell is bash.

The origin of this was actually capitalism that bordered on religion.

In the UNIX Wars of old, Sun and AT&T attempted to take unreasonable control of System V, which included the Korn shell.

DEC, IBM, HP, and others responded with POSIX.

https://en.wikipedia.org/wiki/Unix_wars

The impact upon the Korn shall was actually to reduce functionality, and a number of features were removed (arrays, coprocesses, etc.). The reason for this is that the source code for the Korn shell was configured to compile to a 64k text segment (for 286-Xenix), and readability/maintainability was sacrificed.

Due to this lineage of the POSIX shell, it is very friendly for embedded systems and other constrained environments in ways that its descendants and competitors are not (and can never be).

It deserves to be distinguished from Bash, without question.

> It deserves to be distinguished from Bash, without question.

Absolutely, and I agree with your sentiment at a broad level -- although I think the book notes who the book is for, and that `bash` and `sh` are distinct, it doesn't explain the why of maybe considering `sh` for other uses which aren't really the focus of the book, and perhaps it should?

> Due to this lineage of the POSIX shell, it is very friendly for embedded systems and other constrained environments

I'm wondering if this will matter as much in the future. Are people really going to be programming 16 bit microcontrollers when a 32 bit parts are becoming so cheap? How constrained are we really going to be?

Here is my copy of Busybox for Windows:

  C:\Users\chasil>busybox bash
  ~ $ a[1]=1
  bash: a[1]=1: not found
  ~ $

Despite what Busybox claims, that is very much not Bash. That is Almquist, with a few added bashisms.

I was in a clothing store a few months ago, and their credit card readers had crashed. They were showing the Busybox copyright notice.

     a[1]=1

     $ echo $SHELL

/bin/ksh

This is mksh from MirBSD under Hyperbola Linux.

A little revisionist since POSIX had its seeds in 1984, which was long before the SVR4 collaboration.

Giving DEC, IBM, and HP credit for POSIX is a little odd. They were actually the biggest beneficiaries of the fragmented nature of Unix, with their proprietary flavors. AIX vs HPUX vs DEC Unix all meant that Ken Olsen could pretend to support Unix and at the same time tell the world that "Unix is snake oil".

In college during the introduction to command-line class the professor simply required everyone to write only POSIX-compliant shell scripts. And your shell scripts must work with newlines in file names. We did fun things like parsing (a subset of) HTML using only sed (did you know about sed's hold space and pattern space?). It was basically an intellectual puzzle for geeks with too much time on hand.

> did you know about sed's hold space and pattern space?

I did!

https://perl.plover.com/yak/HoldSpace/

IMO, the year is 2022, almost 2023. Trying to do POSIX sh is tying both arms behind your back. Set the shebang to #!/bin/bash, and now you've got at least got only one arm tied behind your back.

If your environment somehow lacks bash, consider that the bug, and get bash.

Or, untie both arms, and use a language that's not going to take every opportunity to stab you in the back with subtle idiocies dating from the last millennium.

(But I do agree that, if you're going to put down a bash-ism, it's bash, not POSIX sh.)

May I suggest that you attempt to convince The Austin Group/Open Group of your position, to update what was originally known as the POSIX.2 shell standard?

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

http://www.opengroup.org/austin/faq.html

posix is a messy codification of a situation that existed at a particular point in time. it didn't arrive ex nihilo.

if enough people decide to just use bash, then that will be the new standard. we don't have to ask for some committee's permission to advance.

Bash as itself, or POSIXLY_CORRECT Bash?

It does have something of a split personality on that question.

The only entity that still respects the Open Group is the sod submitting the SUS/POSIX submissions for macOS on behalf of Apple.

> Or, untie both arms, and use a language that's not going to take every opportunity to stab you in the back with subtle idiocies dating from the last millennium.

Are you still referring to bash here?

what kind of circumstance are people in where they can use posix sh but not bash? in the year 2022? I don't understand it. fucking everything has bash nowadays. and if you're on some machine that unaccountably doesn't have bash, then why can't you just sudo apt install bash, or scp the binary over and chmod +x it?

if you can't even do that, maybe reevaluate what life choices got you to this place. life is too short to write strictly posix sh.

> posix sh but not bash?

Many non-Linuxes, and some Linuxes too.

> why can't you just sudo apt install bash

Linux is not the whole world. Debian is not the whole Linux. Interactive shells on servers are not guaranteed to be available. Control over the installation image is not guaranteed, or always desirable.

> life is too short to write strictly posix sh

Alas. Life is too short for writing or responding to uninformed rants. Yet here we both are.

POSIX shell scripting has its place. It's not as difficult or complicated as you imagine. The portability tradeoff is valuable or essential in many real-world cases.

>Many non-Linuxes, and some Linuxes too.

which ones can't run bash?

>Linux is not the whole world. Debian is not the whole Linux. Interactive shells on servers are not guaranteed to be available. Control over the installation image is not guaranteed, or always desirable.

I didn't literally mean "sudo apt install", I meant "install the thing by whatever means is appropriate to the platform". if you can't install anything then what are you actually doing with it? you have to get your software onto it somehow.

and at any rate, the article is literally called "the Linux Command Line"

>The portability tradeoff is valuable or essential in many real-world cases.

like what? seriously, what?

I don't get it. I understand software that has weird/harsh requirements because it's on a super constrained embedded platform. that's a real limitation. but being able to run posix sh but not bash seems like an entirely artificial problem. there's no rigorously conceivable resource constraint that would do that. if your unix is so fucking degenerate that it can't run bash then that's a problem of your own choosing.

anyway if it's so easy, you can take on the burden of porting scripts from bash to sh yourself, instead of annoying the rest of us with the "bashisms" whining.

No whining here. I just think you're thinking too small.

bash is usually convenient. When it's not convenient, it might be impossible. Shell scripts with long lives or broad usefulness should be portable.

POSIX sh is just not that scary. It just takes a little extra discipline. It's an appropriate choice, more often than not.

Android as policy does not allow GPL software in userspace.

The MirBSD Korn shell, mksh, is used there as the system shell.

That footprint is huge.

Some utilities that I have used on Android bring a copy of Bash along, but it's not standard.

I also mentioned above that I do some shell scripting with Busybox-win64. I can't use arrays in the "bash" that it implements.

I've also worked on routers that use the Busybox shell, same problem.

Dash is also far smaller and advertised as 4x faster than Bash. Anything I write that targets dash will run on all the others, so this skill is quite useful.

Okay yes, I forgot about the GPL problem. That's a fair reason.

Modern Ubuntu/Debian ship with bash?

``` ubuntu@primary:~$ uname -a

Linux primary 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:56:13 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

ubuntu@primary:~$ echo $SHELL

/bin/bash ```

dash is the default `/bin/sh` but the default shell is still bash. (man sh gives you dash's man)

Bash is the default interactive shell assigned to new users in /etc/passwd.

This is different from /bin/sh, which is Almquist.

So just put `#!/usr/bin/env bash` at the top of the file

> The entire Debian/Ubuntu family has chosen the Almquist shell because of speed and standards compliance, and many things in this book will not work there.

So Debian/Ubuntu ship completely without Bash? According to [1], it's Bash, but it might be outdated.

[1] https://wiki.debian.org/Bash

Bash is shipped in Debian/Ubuntu, but as /bin/bash, not as /bin/sh.

What is shipped as /bin/sh is described here:

http://gondor.apana.org.au/~herbert/dash/

From the EPEL RPM:

"DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. It does this without sacrificing speed where possible. In fact, it is significantly faster than bash (the GNU Bourne-Again SHell) for most tasks."

Hm but the default shell is still bash. It would make sense that "bashisms" don't work on "sh". You should use bash or bash derivatives (zsh) for bashisms.

I think the bigger stumbling block is that people often can't differentiate bashisms from basic shell scripting.

bash is the default interactive shell for users, but dash is the default shell for scripts with a #!/bin/sh shebang (or no shebang, unless they're run from bash), system() calls, etc. This means bashisms will work sometimes, which can be worse than not working at all.

I agree about the importance of differentiating bashisms from basic scripting, but I think the root cause of that is documentation (including this book) that don't make the distinction.

The book is very clear about the fact that it’s using Bash, even noting when a feature requires a newer version, and uses #!/bin/bash for scripts throughout.

...But the foreword for any script could just as easily be `#!/bin/bash`... you're choosing not to use bash. If you're on a system with no bash, and are forced to use `sh`, then just don't use bashisms...

I'm not trying to be difficult, but I just don't see a problem. Explicitly use bash (or a derivative) if you want bashisms, don't if you do not.

FWIW, zsh is not a bash derivative.

Both are spiritual descendants of Bourne shell directly, with some ksh, csh, and tcsh mixed in, in varying proportions.

Yes, a lot of people don't realise that bash (1989) and zsh (1990) are almost the same age and were parallel projects, not derivative.

True, what I really mean was bash compatibility

It's not a problem as long as you remember to declare bash as the interpreter instead of relying on sh to be symlinked to bash.

What's a good alternative book to learn linux command line without bashisms?

I really don't know of one. There should be one.

Reply on news.ycombinator.com