Re: ifs

Re: ifs

[Byron Rakitzis]

I remember talking this over with Paul when I wrote rc. I think we
decided that ifs is akin to pid in that it is a per-shell rather than a
per-environment quantity. We didn't want to force script writers to
initialize ifs to prevent a trojan horse ifs, for example.

So, to answer your question, yes this was a deliberate choice and
is in our opinion correct.

Re: ifs

[Paul Haahr]

>Yes, this all hangs on whether one sees ifs as a per shell or per
>environment property.  It depends on whether you expect:
>        rc -c $cmd
>to be (roughly) identical to:
>        @ eval $cmd
>or not.

they are different.  why not?  what is there that says they should
be the same?  they express two distinct operations; in the case where
the first rc in the path is not rc the shell, they are very different.
(how many of you have had that problem when /etc was in your path?)

>I tend
>to think that the current behaviour is wrong, and would like you to
>reconsider this.  If you still feel it's right, please add something to
>the man page.

i'm very certain i like the current behavior, and thought it was
mentioned on the man page, but would agree that -- if they're not
there -- the non-exported variables should be listed explicitly.
i believe ifs, pid, *, and 0 are it, but perusing the source would
make it certain.

>I'm not entirely convinced by the trojan horse argument -- is certainly
>doesn't exist to the same degree than it did in sh.  By your argument,
>why not disable the export of functions to save people from using
>builtin to prevent trojan horse commands?

this is all very vague in my memory, but i think it's because ifs
was otherwise automatically inherited by the commands inside the
backquotes, which was almost certainly the wrong thing for the
default case.  for example,

        ifs = ':' { passwd = `foobar /etc/passwd` }

where foobar is an rc script that does lots of things, and then
finally prints a line of its input file.  among the things that
it does, foobar uses backquotes at one point.  the non-exporting
of ifs was done so that the author of the above command wouldn't
have to worry about how foo is written.  similarly, i think it
is reasonable that the author of foobar doesn't have to set foobar

>I'm more in favour of flexibility.  I tend towards prefering to allow
>the programmer to explicitly over-ride functions and ifs (by using
>builtin and setting ifs) or to inherit the user's preference from the
>environment.

i think this is where we disagree.  i don't consider ifs a user
preference setting.  it's a parameter to backquote.  as far as
i'm concerned it's an internal piece of a shell script.

but remember, i'm responsible for the `` monstrosity.

>We are all used to setting path and using builtin, why is
>setting ifs so different?

i don't set path or use builtin in functions very often, because
i want to defer to the user's choices.  these i do consider
preferences.

>Besides, I wouldn't trust Paul's view -- he's on record as being
>prejudiced against innocent state variables. :-)

i have nothing against innocent state variables, it's just that
i presume them guilty until proven otherwise.

paul

Re: ifs

[Alan Watson]

Yes, this all hangs on whether one sees ifs as a per shell or per
environment property.  It depends on whether you expect:

	rc -c $cmd

to be (roughly) identical to:

	@ eval $cmd

or not.  (Yes, I know about the magic $pid variable, but its odd
behaviour is dictated by reasons firmly rooted in pragmatism.)  I tend
to think that the current behaviour is wrong, and would like you to
reconsider this.  If you still feel it's right, please add something to
the man page.

I'm not entirely convinced by the trojan horse argument -- is certainly
doesn't exist to the same degree than it did in sh.  By your argument,
why not disable the export of functions to save people from using
builtin to prevent trojan horse commands?  

I'm more in favour of flexibility.  I tend towards prefering to allow
the programmer to explicitly over-ride functions and ifs (by using
builtin and setting ifs) or to inherit the user's preference from the
environment.  We are all used to setting path and using builtin, why is
setting ifs so different?

Besides, I wouldn't trust Paul's view -- he's on record as being
prejudiced against innocent state variables. :-)

ifs

[Alan Watson]

Whilst testing a read that performs ifs splitting, I discovered to my
surprise that ifs is not exported into the environment and so is
initialized to the standard space, tab, and newline whenever rc is
run.  One consequence of this is that the following two commands are
different:

	ifs = ( : $nl ) rc -c 'line = `{ sed 1q /etc/passwd } ; echo $line'
	rc -c 'ifs = ( : $nl ) ; line = `{ sed 1q /etc/passwd } ; echo $line'

Is this really the correct behaviour?  I can understand this choice
with regard to IFS and sh because of the IFS loophole, but this does
not apply to rc.