4 ms·

He meant "impressive chunk of bash" (.sh) not "of shit"

by lecarore 7y ago

kick 7y ago
It's not bash, it's a shell script. bash is not POSIX-compliant. This script is.
- saagarjha 7y ago
  Bash is POSIX compliant, but it has a number of extensions.
  - kick 7y ago
    No, it isn't. You have to explicitly enable a POSIX-compliant mode: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html https://www.gnu.org/software/bash/manual/html_node/Bash-POSI...
    - saagarjha 7y ago
      That still makes it POSIX compliant…
      - kick 7y ago
        If you have to set a mode to make it so, it isn't.
        throwaheyy 7y ago
        No, it is. An x86-64 CPU boots in 16-bit real mode. An explicit option has to be used to switch it to 64-bit long mode. That doesn’t mean that it’s not a 64-bit CPU.
        deleted 7y ago
        [deleted]
        wizzwizz4 7y ago
        When executed as /bin/sh, Bash enables POSIX mode automatically. /bin/bash isn't POSIX compliant by default, but /bin/sh symlinked to /bin/bash is, so you can be sure that #!/bin/sh will be POSIX-like even when implemented by Bash.
      - kps 7y ago
        Not entirely. $ echo I am posix compliant &>/dev/null
    - deleted 7y ago
      [deleted]
- quotemstr 7y ago
  A script for bash is a shell script. I've never understood this tic some people have about writing shell scripts executable by strictly minimal POSIX-compliant shells: nobody needs that level of strictness. Everyone has bash. Everyone can easily get zsh too. Why should I spend one minute of my time worry about whether ksh93 or dash or something can run my script when I can just put bash in the shebang line and get access to a much richer feature set? It makes no sense. Portability for portability's sake is a waste of time.
  - saagarjha 7y ago
    I keep my dotfiles bootstrapping script POSIX-compliant; it’s a little bit of a pain but it lets me use it in really stripped down environments.
  - saxonww 7y ago
    It's pretty common to run into environments without bash, or without the bash your script needs. Three examples would be any Docker container based on Alpine (just ash), OpenBSD which ships with (I think) a Korn shell, and macOS which is stuck at Bash 3.x. Similarly, not every Linux distribution puts bash in the same place, e.g. NixOS. So blindly putting `#!/bin/bash` as your shebang will result in a broken script on those systems. You can just install bash or move it around to suit your script, but maybe you're shipping this script for other people to use and can't control their environments. It's easier to make a handful of changes to the script instead. This is why some people care about portability.
  - derefr 7y ago
    There used to be a lot more POSIX OSes; most of them, other than Linux and the BSDs, don’t have Bash, but instead only some other default shell. (Remember the https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem ? Xenix? Solaris?) But the modern reason is https://en.wikipedia.org/wiki/Almquist_shell https://en.wikipedia.org/wiki/Almquist_shell (ash) and its descendant, dash. Busybox environments ship with ash as the only available shell, unless you manually build another shell into the busybox chroot. As well, many initrd/initramfs environments have only one shell, usually dash. When scripting either of these, you have to write pure POSIX scripts. And—mostly due to inertia—this tends to apply to all such environments, no matter their size. My Synology NAS (because it’s technically a busybox env) doesn’t have bash, despite having huge honking disks! Neither does CoreOS (because it’s technically a PXE initramfs env), despite not being intended as a “link-bandwidth-constrained” PXE environment at all. They’re just descended from these “lineages” of OSes that were used on more constrained devices in more constrained times, so their maintainers have kept to the old embedded-system ways. On top of this, as the ash wiki article says, Debian made a choice to make dash their /bin/sh, and then forced all system scripts to use it, thus forcing them to be rewritten to be POSIX-compatible. (I think this was done with goal of lower memory-usage for constrained Debian environments that might still need to install some arbitrary subset of Debian system services.) There was also another kind of pressure, 10-20 years ago, with Linux single-floppy or low-link-bandwidth PXE boot environments wanting to be as slim as possible, and therefore not shipping with bash.

He meant "impressive chunk of bash" (.sh) not "of shit"

kick 7y ago

It's not bash, it's a shell script. bash is not POSIX-compliant. This script is.

saagarjha 7y ago
Bash is POSIX compliant, but it has a number of extensions.
- kick 7y ago
  No, it isn't. You have to explicitly enable a POSIX-compliant mode: https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html https://www.gnu.org/software/bash/manual/html_node/Bash-POSI...
  - saagarjha 7y ago
    That still makes it POSIX compliant…
    - kick 7y ago
      If you have to set a mode to make it so, it isn't.
      - throwaheyy 7y ago
        No, it is. An x86-64 CPU boots in 16-bit real mode. An explicit option has to be used to switch it to 64-bit long mode. That doesn’t mean that it’s not a 64-bit CPU.
        deleted 7y ago
        [deleted]
      - wizzwizz4 7y ago
        When executed as /bin/sh, Bash enables POSIX mode automatically. /bin/bash isn't POSIX compliant by default, but /bin/sh symlinked to /bin/bash is, so you can be sure that #!/bin/sh will be POSIX-like even when implemented by Bash.
    - kps 7y ago
      Not entirely. $ echo I am posix compliant &>/dev/null
  - deleted 7y ago
    [deleted]
quotemstr 7y ago
A script for bash is a shell script. I've never understood this tic some people have about writing shell scripts executable by strictly minimal POSIX-compliant shells: nobody needs that level of strictness. Everyone has bash. Everyone can easily get zsh too. Why should I spend one minute of my time worry about whether ksh93 or dash or something can run my script when I can just put bash in the shebang line and get access to a much richer feature set? It makes no sense. Portability for portability's sake is a waste of time.
- saagarjha 7y ago
  I keep my dotfiles bootstrapping script POSIX-compliant; it’s a little bit of a pain but it lets me use it in really stripped down environments.
- saxonww 7y ago
  It's pretty common to run into environments without bash, or without the bash your script needs. Three examples would be any Docker container based on Alpine (just ash), OpenBSD which ships with (I think) a Korn shell, and macOS which is stuck at Bash 3.x. Similarly, not every Linux distribution puts bash in the same place, e.g. NixOS. So blindly putting `#!/bin/bash` as your shebang will result in a broken script on those systems. You can just install bash or move it around to suit your script, but maybe you're shipping this script for other people to use and can't control their environments. It's easier to make a handful of changes to the script instead. This is why some people care about portability.
- derefr 7y ago
  There used to be a lot more POSIX OSes; most of them, other than Linux and the BSDs, don’t have Bash, but instead only some other default shell. (Remember the https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem ? Xenix? Solaris?) But the modern reason is https://en.wikipedia.org/wiki/Almquist_shell https://en.wikipedia.org/wiki/Almquist_shell (ash) and its descendant, dash. Busybox environments ship with ash as the only available shell, unless you manually build another shell into the busybox chroot. As well, many initrd/initramfs environments have only one shell, usually dash. When scripting either of these, you have to write pure POSIX scripts. And—mostly due to inertia—this tends to apply to all such environments, no matter their size. My Synology NAS (because it’s technically a busybox env) doesn’t have bash, despite having huge honking disks! Neither does CoreOS (because it’s technically a PXE initramfs env), despite not being intended as a “link-bandwidth-constrained” PXE environment at all. They’re just descended from these “lineages” of OSes that were used on more constrained devices in more constrained times, so their maintainers have kept to the old embedded-system ways. On top of this, as the ash wiki article says, Debian made a choice to make dash their /bin/sh, and then forced all system scripts to use it, thus forcing them to be rewritten to be POSIX-compatible. (I think this was done with goal of lower memory-usage for constrained Debian environments that might still need to install some arbitrary subset of Debian system services.) There was also another kind of pressure, 10-20 years ago, with Linux single-floppy or low-link-bandwidth PXE boot environments wanting to be as slim as possible, and therefore not shipping with bash.