From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Tue, 17 Oct 2017 16:18:41 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="001a113e50006a11ce055bbfa376" Subject: Re: [9fans] Why Plan 9 uses $ifs instead of $IFS? Topicbox-Message-UUID: c31212e0-ead9-11e9-9d60-3106f5b1d025 --001a113e50006a11ce055bbfa376 Content-Type: text/plain; charset="UTF-8" > > 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 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 : > >> On Tue, Oct 17, 2017 at 10:38 AM, Giacomo Tesio 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. >> >> > --001a113e50006a11ce055bbfa376 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
since for example the original Rc= paper still referred to $IFS.

reall= y? the only references to IFS I can find are in comparisons of $ifs to the = Bourne shell's $IFS=C2=A0

On 17 October 2017 at 16:05, Giacomo Tesio <giacomo= @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 flip= s the question a bit: I wonder why the same designers chose uppercase varia= ble names while designing Unix... :-)


Giacomo

2017-10-17 16:39 GMT+02:00 Dan Cross = <crossd@gmail.com<= /a>>:
On Tue, Oct 17, 201= 7 at 10:38 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
> Out of curiosity, do anybody know why Plan9 designers chose lowercase<= br> > 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, su= ch
> 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.



--001a113e50006a11ce055bbfa376--