Package: dash
Version: 0.5.5.1-7.4
Severity: normal
I'm not really quite sure exactly how to file this report, as it
involves interactions between 'csh', 'kdm', and 'dash', but
'dash' seems the obvious place to initially file the report,
as it appears to me that there may be a POSIX compliance issue,
or at least an inconsistency in how 'dash' handles 'export'.
A description of the immediate problem:
- User uses 'tcsh' as login shell.
- User has a .cshrc with:
setenv 500_FOO 'blather'
- User attempts to login using KDE 'kdm'.
- /etc/kde4/kdm/Xsession uses the following "hackery" to attempt to
inherit/import a '*csh' user's standard environment into its own
shell environment via:
$SHELL -c "if (-f /etc/csh.login) source /etc/csh.login; if (-f ~/.login)
source ~/.login; /bin/sh -c export -p >! $xsess_tmp"
. $xsess_tmp
- However, 'dash' when dot-script sourcing "$xsess_tmp" finds the statement:
export 500_FOO='blather'
and immediately aborts dot-script processing (so no subsequent
statements are read). In this case, because 'dash' also returns
exit status "2" from the dot-script source, 'Xsession' aborts and
the user is immediately logged out.
So, Xsession could be potentially reworked to ignore the error, or could do:
. $xsess_tmp || true
(which would not abort the Xsession login, at least, but would still
leave the user without a complete standard environment and little
indication of what failed) or, possibly, a bunch of undesireable
POSIX sanitization could be done on the 'export -p' output file to
keep dash from aborting when dot-script sourcing of it...
FWIW, 'bash' behaves differently on this error (it also writes
BASH-specific 'declare' statements instead of 'export' for
'export -p' (uck)), by continuing to process the remainder of
the file and returning exit status = 0. (that's assuredly from
other valid statements further down the file, actually, i
just hand-edited the file, and '.' returns exit code=1 if
that statement is at the end of the dot-script, still different
from exit code '2' as 'dash' reports)
--------------
It appears that 'dash' will inherit a "POSIX non-compliant" env-var
into the environment, and is happy to write the value out in an
'export -p' statement to a temp file, but upon doing a dot-script
source of the temp file will abort processing of the dot-script and
return exit status of "2".
I'm not entirely clear on whether this apparent behavioural
inconsistency is correct. (seems to me that if dash writes something
out with 'export -p' that whatever it wrote out should be invertably
parsable w/o error)
These seem to be possibly relevant references on expected behaviour:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_14
'export' appears to be a "Special Built-In Utility"
'dot' appears to be a "Special Built-In Utility"
"A syntax error in a special built-in utility may cause a shell executing that
utility to abort"
"If a special built-in utility encountering a syntax error does not abort the
shell, its exit value shall be non-zero."
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_01
2.8.1 Consequences of Shell Errors
http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html
EXIT STATUS=Zero.
CONSEQUENCE OF ERRORS=Default
sdowdy$ /bin/bash -c 'export 500_FOO=wompus; echo $?'
/bin/bash: line 0: export: `500_FOO=wompus': not a valid identifier
1
sdowdy$ /bin/dash -c 'export 500_FOO=wompus; echo $?'
export: 1: 500_FOO: bad variable name
# fails to execute the following statement regardless of 'errexit' state
sdowdy$ echo $?
2
http://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html
EXIT STATUS=Returns the value of the last command executed, or a zero exit
status if no command is executed.
CONSEQUENCES OF ERRORS=Default.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
...Environment variable names used by the utilities in the Shell
and Utilities volume of POSIX.1-2008 consist solely of uppercase
letters, digits, and the <underscore> ( '_' ) from the characters
--> defined in Portable Character Set and do not begin with a
--> digit. Other characters may be permitted by an implementation;
--> applications shall tolerate the presence of such names. Uppercase
and lowercase letters shall retain their unique identities and
shall not be folded together. The name space of environment
variable names containing lowercase letters is reserved for
applications. Applications can define any environment variables with
names from this name space without modifying the behavior of the
standard utilities....
(so does "tolerate" mean that 'dash' should not abort dot-scripts
with invalid env-var assignments?)
thanks,
--stephen
-- System Information:
Debian Release: 6.0.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages dash depends on:
ii debianutils 3.4 Miscellaneous utilities specific t
ii dpkg 1.15.8.13 Debian package management system
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
dash recommends no packages.
dash suggests no packages.
-- debconf information:
* dash/sh: true
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
