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" <[EMAIL PROTECTED]> To: "Debian Bug Tracking System" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <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 > >
