From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from colossus.apple.com ([130.43.2.6]) by hawkwind.utcs.toronto.edu with SMTP id <2683>; Wed, 6 Oct 1993 15:14:51 -0400 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Jun-1993-eef) id AA09458; Wed, 6 Oct 93 12:00:16 -0700 for Received: from [130.43.11.214] (kip-24.kaleida.com) by talisman.kaleida.com (4.1/SMI-4.1) id AA10923; Wed, 6 Oct 93 11:56:51 PDT Date: Wed, 6 Oct 1993 14:56:49 -0400 Message-Id: <9310061856.AA10923@talisman.kaleida.com> To: Alan Watson From: haahr@kaleida.com (Paul Haahr) X-Sender: haahr@talisman.kaleida.com Subject: Re: ifs Cc: rc@hawkwind.utcs.toronto.edu >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