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
