Hacker News Reader

Comment by m4r35n357 | Hacker News Reader

It is far simpler to just learn the POSIX shell first - much shorter man page. The the Bash stuff is then just a few additions if you ever need them (other shells are available).

View on HN

Indeed, I an older version of https://pubs.opengroup.org/onlinepubs/9699919799.2018edition... in two weekends. (I never got around to implementing job control).

While doing so, I found a part of the specification that (as far as I can tell) no shell implements (sourcing my /etc/profile failed with my shell due to the difference): the specification blesses (at the time)[1] 20 utilities that should be run without regards to the PATH, but any other built-ins should not be run if the command does not exist in the path.

So, for example:

    PATH=""
    echo "Hello"

Should fail on every POSIX compliant shell. I haven't found a shell that implements echo as a builtin in which the above fails though.

1: Now it has a larger list for which it is unspecified what happens. See "Command search and execution" for the list. "echo" is not on the list though, so my example is still well-defined in POSIX yet breaks on all shells I tried.

You want the Watanabe shell in its POSIX-conformant mode.

* https://unix.stackexchange.com/a/496291/5132

* https://unix.stackexchange.com/a/496377/5132

Also observe the /opt/ast/bin mechanism in the '93 Korn shell.

Wow, someone actually did it! When I reported this non-conformance to the dash mailing-list, I first got pushback that I was wrong about the spec, and then once I convinced them I was right the response was something along the lines of "that's stupid why would we do that"

Notably, such a concept as a function having a local variable is beyond POSIX shell.

"Variables may be declared to be local to a function by using a 'local' command."

Here's the spec. Where is it? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

It is in both ash and dash, the shells I mentioned. Your attempt at point scoring is irrelevant but expected.

ash & dash are about 100kB executables (POSIX plus a tiny number of non-interactive improvments like 'local'), bash is 1100kB. Every shell and subshell.

My point is that POSIX shell purity is masochism. Understanding how it's the core and other shells build on top of it is certainly valuable, but it's not inherently particularly good to use.

Maybe we are at cross purposes. My default shell is bash, but my default "sh" is dash. This is as it should be (and is default in Debian & Ubuntu I think).

If you are talking about interactive use, of course bash is the one to use, but for writing shell scripts, it is a 10X interactivity overhead" over dash.

IMO it's a big win for scripts to at least be able to use Arrays in that otherwise "stringly-typed" world.

As a POSIX shell masochist myself, Arrays are the single biggest missing feature. POSIX shells actually do have one array: $@. Having more would make my life so much easier.

The amount of gyrations I go through to account for the lack of arrays is easily 1000x worse than accounting for not having local variables.

Indeed, and local is one of the few non-POSIX things that Debian people famously could not live without, and so is required to exist in all Debian shells that can be used as /bin/sh such as the Debian Almquist shell.

* https://debian.org/doc/debian-policy/ch-files.html#s-scripts

What man page is that? On OS/X and redhat, man sh brings up the Bourne Shell man page.

If the default sh is set to bash (yuk!) you will need to use ash or dash to get the basic POSIX shell and man page. On my Xubuntu 18.04 system, "man sh" brings up the dash man page.

Thanks for nothing RedHat & Apple!

There really isn't a POSIX sh manual page; and you are conflating Bourne with Bourne Again on RedHat.

The closest that anyone comes is, I believe, OpenBSD. The ksh(1) manual page is the PD Korn shell manual. And the separate sh(1) manual page "describes only the features [of ksh] relevant to a POSIX shell".

On others, sh(1) is usually the manual page for one of the named shells.

Debian and Ubuntu's sh(1), for example, is the dash(1) for the Debian Almquist shell, which is famously not a POSIX sh, because it explicitly includes 3 extensions that Debian people could not bear to part with in their big project of over a decade ago to remove bashisms from package maintainer scripts and suchlike.

On my distribution (Arch Linux) the `sh` tool comes from the `bash` package, and is partially shared code I believe, though I'm unsure exactly how they are related at this point.

On Arch, `/bin/sh` is a symlink to `bash`. When Bash is invoked with the name `sh`, it behaves closer to the historical Bourne shell. The differences between normal Bash behavior and the behavior when invoked as `sh`:

- It behaves as if `--posix` was given.

- It behaves as if `--norc` was given.

- If it looks for a user profile file (i.e. it is a login shell), then it only looks at ~/.profile (instead of the usual behavior of giving precedence to ~/.bash_profile then ~/.bash_login then ~/.profile)

- At startup, if $ENV is set, it `source "$ENV"`.

Reply on news.ycombinator.com