Also, why NPROC has been left uppercase? :-)
Giacomo 2017-10-17 17:45 GMT+02:00 Giacomo Tesio <giac...@tesio.it>: > 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 <charles.fors...@gmail.com>: > >> 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 <giac...@tesio.it> 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 <cro...@gmail.com>: >>> >>>> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio <giac...@tesio.it> >>>> 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. >>>> >>>> >>> >> >
