Comment by chasil

1 year ago

Nope nope nope.

You can see this in a script by defining:

  alias p=printf

Then try to use it with bash. If bash is running as #!/bin/sh, then it will work, because bash is forced into POSIX mode.

However, if the script is running as #!/bin/bash, then you will be in the '80s behavior, and it will fail.

Try it.

7 comments

chasil

jchw 1 year ago

Bash isn't part of GNU coreutils.

chasil 1 year ago
I realize that, but I'm illustrating that POSIX.2 required a retrofit to bash, and probably required similar adjustments to the rest of userland, including coreutils.
- jchw 1 year ago
  
  I knew about the fact that bash behaves quite differently in POSIX mode, but that isn't much of a problem in most cases since nobody is forcing you to use a POSIX-compatible bourne shell as your login shell or for scripting, it's just the shell that you can guarantee will exist if something is POSIX compliant, right? If I were addressing bash, I would've said set -o posix instead of POSIXLY_CORRECT. (I didn't even realize POSIXLY_CORRECT did anything to bash.)
  The GNU bash documentation covers the differences pretty well:
  https://www.gnu.org/software/bash/manual/html_node/Bash-POSI...
  GNU coreutils however, the behavior differences seem rather minor, and I couldn't find exhaustive documentation. However, I may as well try to back this up with more than conjecture since we're already this deep in the thread. Let's dig into GNU coreutils and see what POSIXLY_CORRECT appears to do as of current git HEAD:
  - cp: Allow the destination to be a dangling symlink when POSIXLY_CORRECT is set.
  - dd: Does not trap SIGINFO if it's equal to SIGUSR1 (default) and POSIXLY_CORRECT is set. I guess this means that POSIXLY_CORRECT makes the `pkill -USR1 dd` thing not work?
  - df: Use 512-byte block size if POSIXLY_CORRECT is set, otherwise 1024.
  - echo: POSIXLY_CORRECT disallows parsing options unless the first option is `-n`, and enables parsing "v9"-style interpretation of backslash escapes. Demonstration: `$(which echo) -e \\n`
  - id: Will not print SELinux context even when --context is passed. Not sure why. This is the only thing I've seen that explicitly disables functionality.
  - nohup: The exit code for internal failures is 127 instead of 125 when POSIXLY_CORRECT is set.
  - pr: Changes default date format when POSIXLY_CORRECT is set.
  - printf: POSIXLY_CORRECT disables a warning about ignored characters following a character constant. Demonstration: `$(which printf) %x "'xx"` - same output in both modes, but in POSIXLY_CORRECT you are not warned about the second x being ignored.
  - pwd: Defaults to using -L ("logical" mode, uses $PWD value as long as it refers to the CWD) instead of -P.
  - readlink: Defaults to --verbose if POSIXLY_CORRECT is set.
  - sort: Allow operands to be parsed after files if POSIXLY_CORRECT is not set.
  - touch: Seems to disable some kind of warning when an invalid date is passed.
  - uniq: Seems to be the same as sort.
  - wc: Treats non breaking space characters as word delimiters, if POSIXLY_CORRECT is unset.
  I believe this is an exhaustive list as of GNU coreutils f4dcc2a495c390296296ad262b5a71996d0f6a86.
  
  4 replies →