From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Schaible, Joerg" To: cygwin@cygwin.com Subject: RE: bash: setenv: command not found Date: Thu, 08 Feb 2001 07:57:00 -0000 Message-id: X-SW-Source: 2001-02/msg00448.html Hi Christopher >Today, Chet Ramey wrote: >> > >> > 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. >> > >> >> 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