Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
- To: Debian Bug Tracking System <email@example.com>
- Cc: firstname.lastname@example.org, email@example.com
- Subject: Re: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
- From: "Zack Weinberg" <zackw@Stanford.EDU>
- Date: Mon, 30 Apr 2001 12:16:16 -0700
- Message-id: <[🔎] 20010430121616.E6612@stanford.edu>
- In-reply-to: <handler.95430.D95430.firstname.lastname@example.org>; from email@example.com on Fri, Apr 27, 2001 at 05:07:30AM -0500
- References: <20010427200525.A31088@gondor.apana.org.au> <200104270722.f3R7MJZ25848@smtp2.Stanford.EDU> <handler.95430.D95430.firstname.lastname@example.org>
> On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
> > ash 0.3.8-1 incorporates changes in word splitting which break common
> > shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
> > when compiling GCC.
> > #! /bin/ash
> > OIFS=$IFS
> > IFS=,
> > set `echo fnord,a,b,c`
> > IFS=$OIFS
> > CMD="echo $@"
> > $CMD
> Sorry, but this is broken. This assumes that IFS is set to begin with
> which may not be the case.
I have consulted the Single Unix Standard and can find only dubious
justification for this assertion. It never flat out says whether IFS
is to be set on entry to the shell or not. However, I note this
# Input field separators: a string treated as a list of characters
# that is used for field splitting and to split lines into fields
# with the read command. If IFS is not set, the shell will behave
# as if the value of IFS were the space, tab and newline
# characters. (See Field Splitting .)
I could read that as requiring that if IFS is unset, then you get
"<space><tab><newline>" if you inspect its value, NOT the null string.
In any case, your change is a gratuitous divergence from the upstream
code and a deliberate breakage of consensus shell behavior. My script
functions correctly with every Bourne-descended shell I have access to
except ash 0.3.8-1. (In addition to bash, pdksh, and previous
versions of ash, I tried the /bin/sh provided by Solaris, HP-UX, IRIX,
and Digital Unix, and the /bin/ksh and /usr/xpg4/bin/sh provided by
Solaris.) Irrespective of what the standard says, you cannot
introduce changes into /bin/sh which make it behave differently from
every other shell out there. Especially if they have the potential to
break every shell script which uses some feature.
I had hoped that you had learned your lesson from the last time you
pulled a stunt like this. It seems I was wrong.