Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14486 > unrolled thread

"sh -a" sets the POSIXLY_CORRECT *environment* variable

Back to article view | Back to gnu.bash.bug

Contents

  "sh -a" sets the POSIXLY_CORRECT *environment* variable Stephane Chazelas <stephane.chazelas@gmail.com> - 2018-08-14 16:50 +0100

#14486 — "sh -a" sets the POSIXLY_CORRECT *environment* variable

Hi,

This is from
https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt
(original investigation by Mark Plotnick)

Though not documented, enabling the POSIX mode in bash whether
with

- bash -o posix
- sh
- env SHELLOPTS=posix bash
- set -o posix # within bash

causes it to set the value of the $POSIXLY_CORRECT shell
variable to "y" (if it was not already set)

What is documented is that when that variable is set, then bash
enters the POSIX mode.

Now, that variable is understood as "enter POSIX mode" for many
GNU utilities and several non-GNU utilities (like those using
the GNU getopt API) not just bash.

When bash enters the POSIX mode while the allexport option is
on,  like in:

- sh -a
- sh -o allexport
- bash -o posix -o allexport...
- env SHELLOPTS=posix,allexport bash
- set -o posix # within bash -a

Then that POSIXLY_CORRECT ends up in the environment of all
commands started by that bash thereafter, which means they start
behaving differently.

IMO, bash's posix mode should only affect bash and its builtin
commands, not the other commands started within bash.

That a #! /bin/sh -a script should make all commands within
behave POSIXly is unexpected and means a script will behave
differently if /bin/sh is bashed on bash or another shell.

Maybe bash should not set POSIXLY_CORRECT, or not export it when
it sets it by itself. If it sets it, the documentation should
reflect it.

Maybe more generally, I think with allexport, bash should not
export the variables that it sets itself. One uses that option
for the variables they set to be available in other scripts
called within. It doesn't make sense to export things like
BASH_VERSION, BASHPID, OPTIND.

Per POSIX, "the export attribute shall be set for each variable
to which an assignment is performed (see Variable Assignment)",
though it goes on about getopts and read even though those are
not listed under "Variable Assignment".

In
set -a
getopts o VAR
printenv VAR

Some shells export VAR, few export OPTIND.

few export VAR in

set -a
for VAR in 1; do printenv VAR; done

(even though here I'd say it could be desirable).

All export it in "read VAR".

In any case, I think the POSIX specification should be
clarified.

-- 
Stephane

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web