Re: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash: word-splitting changes break shell scripts)
This thread is directed at the wrong bug number - the discussion is about
#95430, but the messages are going to #95420. Please adjust the recipients
appropriately in your replies.
-Ben
----- Original Message -----
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: "Debian Bug Tracking System" <control@bugs.debian.org>
Cc: <95420@bugs.debian.org>; <debian-devel@lists.debian.org>
Sent: Monday, April 30, 2001 3:16 PM
Subject: Bug#95420: Bug#95430 acknowledged by developer (Re: Bug#95430: ash:
word-splitting changes break shell scripts)
> reopen 95420
> quit
>
> ...
> > 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
> paragraph:
>
> # IFS
> # 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.
>
> zw
>
>
Reply to: