Large file system support in 2.1.2 (was Re: [Python-Dev] release for 2.1.2, plus 2.2.1...)

[Martin v. Loewis]

> What do you get?  

martin@mira:~> CFLAGS='one' OPT="two $CFLAGS" ./foo.sh
OPT   = xtwo onex
CFLAGS= xonex
martin@mira:~> echo $BASH_VERSION
2.05.0(1)-release

> What do you *expect* to get?  

What I get, both in zsh and bash. I'd expect environment variable
assignments to be evaluated from left to right, one-by-one. The bash
documentation says

# The order of expansions is: brace expansion, tilde expansion,
# parameter, variable and arithmetic expansion and command
# substitution (done in a left-to-right fashion), word splitting, and
# pathname expansion.

The only way I can produce an error is by

martin@mira:~> env CFLAGS='one' OPT="two $CFLAGS" ./foo.sh
OPT   = xtwo x
CFLAGS= xonex

This is the result of the exact procedure used by bash:

# When a simple command is executed, the shell performs the following
# expansions, assignments, and redirections, from left to right.
#
# 1.  The words that the parser has marked as variable assignments
#     (those preceding the command name) and redirections are
#     saved for later processing.
#
# 2.  The words that are not variable assignments or redirections are
#     expanded.  If any words remain after expansion, the first word
#     is taken to be the name of the command and the remaining words
#     are the arguments.
#
# 3.  Redirections are performed as described above under REDIRECTION.
#
# 4.  The text after the = in each variable assignment undergoes tilde
#     expansion, parameter expansion, command substitution, arithmetic
#     expansion, and quote removal before being assigned to the
#     variable.

So variable left-more assignments have effect on right-more
assignments, but not on any other words in the command line.

> Am I boiling things down correctly?

I would say so. That also indicates the right change to the
documentation: Just put each assignment in an individual export
statement:

export CFLAGS OPT;CFLAGS='one';OPT="two $CFLAGS";./foo.sh

I'm still surprised that it fails on your bash; I get the same (IMO
correct) behaviour with bash 2.03 on Solaris. I get failures with bash
2.02, and with /bin/sh on Solaris. /bin/ksh and /usr/xpg4/bin/sh work
fine (/usr/xpg4/bin/sh actually is ksh).

> So, why should any of this work anywhere?  Should we ever expect $OPT
> to get the right value?
> 
> i-must-be-missing-something-really-obvious,-obvious-ly y'rs,

I'd say (without further research) that this was unspecified for
Bourne Shell, and got clarified for POSIX Shell - so both recent 
Bash versions, and the Solaris ksh work fine.

Regards,
Martin