4 ms·

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 she

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).

frou_dh 7y ago
Notably, such a concept as a function having a local variable is beyond POSIX shell.
- m4r35n357 7y ago
  "Variables may be declared to be local to a function by using a 'local' command."
  - frou_dh 7y ago
    Here's the spec. Where is it? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
    - m4r35n357 7y ago
      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.
      - frou_dh 7y ago
        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.
        m4r35n357 7y ago
        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.
        frou_dh 7y ago
        IMO it's a big win for scripts to at least be able to use Arrays in that otherwise "stringly-typed" world.
        aidenn0 7y ago
        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.
- JdeBP 7y ago
  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 https://debian.org/doc/debian-policy/ch-files.html#s-scripts
commandlinefan 7y ago
What man page is that? On OS/X and redhat, man sh brings up the Bourne Shell man page.
- m4r35n357 7y ago
  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!
- JdeBP 7y ago
  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.
aidenn0 7y ago
Indeed, I an older version of https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html 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.
- JdeBP 7y ago
  You want the Watanabe shell in its POSIX-conformant mode. * https://unix.stackexchange.com/a/496291/5132 https://unix.stackexchange.com/a/496291/5132 * https://unix.stackexchange.com/a/496377/5132 https://unix.stackexchange.com/a/496377/5132 Also observe the /opt/ast/bin mechanism in the '93 Korn shell.
  - aidenn0 7y ago
    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"
nixpulvis 7y ago
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.
- LukeShu 7y ago
  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"`.

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).

frou_dh 7y ago

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

m4r35n357 7y ago
"Variables may be declared to be local to a function by using a 'local' command."
- frou_dh 7y ago
  Here's the spec. Where is it? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
  - m4r35n357 7y ago
    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.
    - frou_dh 7y ago
      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.
      - m4r35n357 7y ago
        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.
        frou_dh 7y ago
        IMO it's a big win for scripts to at least be able to use Arrays in that otherwise "stringly-typed" world.
        aidenn0 7y ago
        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.
JdeBP 7y ago
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 https://debian.org/doc/debian-policy/ch-files.html#s-scripts

commandlinefan 7y ago

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

m4r35n357 7y ago
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!
JdeBP 7y ago
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.

aidenn0 7y ago

Indeed, I an older version of https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html 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.

JdeBP 7y ago
You want the Watanabe shell in its POSIX-conformant mode. * https://unix.stackexchange.com/a/496291/5132 https://unix.stackexchange.com/a/496291/5132 * https://unix.stackexchange.com/a/496377/5132 https://unix.stackexchange.com/a/496377/5132 Also observe the /opt/ast/bin mechanism in the '93 Korn shell.
- aidenn0 7y ago
  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"

nixpulvis 7y ago

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.

LukeShu 7y ago
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"`.