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.
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:
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.
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.
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.
I still run some rhel5, and there were quite a few standard options that were not implemented by GNU.
Looking now is good, but looking in the past is also illuminating.
I generally trust busybox to give me both a uniform and compliant userland, certainly more than rhel5 coreutils.
3 replies →