>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