> > In *rc* you use quotation marks when you want a syntax character to > appear in an argument, or an argument that is the empty string, and at no > other time. IFS is no longer used, *except in the one case where it was > indispensable*: converting command output into argument lists during > command substitution.
So, I undestood: it used to use IFS in that one case. I got it now: the fact that IFS was named ifs was not a relevant for the discourse, and thus omitted. Still I'm a bit surprised that such change in the conventions provides no practical advantage: the taste changes with age, but costs accumulate... :-) BTW, thanks for your answers! Giacomo 2017-10-17 17:18 GMT+02:00 Charles Forsyth <[email protected]>: > since for example the original Rc paper still referred to $IFS. > > > really? the only references to IFS I can find are in comparisons of $ifs > to the Bourne shell's $IFS > > On 17 October 2017 at 16:05, Giacomo Tesio <[email protected]> wrote: > >> Really? Just aesthetics? :-o >> I supposed it had some practical goal I was missing, since for example >> the original Rc paper still referred to $IFS. >> >> This would flips the question a bit: I wonder why the same designers >> chose uppercase variable names while designing Unix... :-) >> >> >> Giacomo >> >> 2017-10-17 16:39 GMT+02:00 Dan Cross <[email protected]>: >> >>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <[email protected]> >>> wrote: >>> > Out of curiosity, do anybody know why Plan9 designers chose lowercase >>> > variables over uppercase ones? >>> > >>> > At first, given the different conventions between rc and sh (eg $path >>> is an >>> > array, while $PATH is a string), I supposed Plan 9 designers wanted to >>> > prevent conflict with unix tools relying to the older conventions. >>> > >>> > However, I'm not sure this was the main reason, as this also open to >>> subtle >>> > issues: if a unix shell modifies $IFS and then invoke an rc script, >>> such >>> > script will ignore the change and keep using the previous $ifs. >>> > >>> > >>> > As far as I can see, APE does not attempt any translation between the >>> two >>> > conventions, so maybe I'm just missing something obvious... >>> > >>> > >>> > Do anyone know what considerations led to such design decision? >>> >>> Aesthetics. >>> >>> >> >
