RE: bash: setenv: command not found

["Schaible, Joerg" <Joerg dot Schaible at gft dot com>]

Hi Christopher

>Today, Chet Ramey wrote:
>> > <soapbox>
>> > yes, this is a stupid naming convention, and it's one
>> > of the things I hate the most about shells... every one
>> > has a different version, and different syntax. There
>> > needs to be ONE standard, and I'm sorry to say BASH's
>> > answer isn't an answer; here csh got it right.
>> > </soapbox>
>> 
>> Why do you say that csh is right and bash is wrong?
>
>call me crazy but I like orthogonality, and logically named
>commands.
>
>setenv/unsetenv is just more intuitively obvious than export/unset
>imho. I also appreciate the lack of an = in the assignments, to me
>at least the construct "export foo=bar" evaluates to "export true"
>which is illogical. (read that as 'export the result of this
>assignment'.) This allows a clean distinction between "foo=bar yada"
>and "setenv foo bar; yada" clearly in the first case foo is only
>assigned 'locally' whereas in the second its being put into the
>environment. You only need one "assignment opperator", either = (do
>it locally) or setenv (globaly) the combination of the two is
>just confusing and redundant.

export in bash is just a convenient version setting an environment variable.
Normally you would write:

set foo=bar
export foo
unset foo

First command sets foo to bar locally, second command puts foo into
environment, third will clear the variable completely. IMHO set/unset is
intuitive enough. Especially if you have to write *portable* shell scripts
for standard sh you have to do it in this way. This csh scripts really annoy
me, since csh is not available in all environments.

Regards,
Jorg

BTW: No, no, I don't wanna start a flame war ...


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple