begin  quoting Mike Marion as of Wed, Mar 02, 2005 at 08:15:59PM -0800:
> Quoting Stewart Stremler <[EMAIL PROTECTED]>:
> 
> >But no, the real implication is that using /bin/bash instead of /bin/sh
> >(or, god forbid, linking /bin/sh to /bin/bash) is harmful and arrogant.
> 
> Ah.. you're referring to portability and such.  No?
 
Yes. Not everyone uses bash. Not everyone has bash installed, nor should
they have to.... especially when the only requirement for bash is in the
first line of the script. :-/

> Yeah, though I tend to use bash over sh myself since I use some of the 
> bash-only tricks.. or at least sometimes have issues with sh vs bash.
> Though my work is like 99.8% linux these days.

I'm pretty evenly split between Linux, Solaris, and OS X.
 
> >Poorly written scripts cause all kinds of problems no matter what they
> >are written in.
> 
> Yeah, but many of the issues we have are due to the usage of csh instead of
> sh/bash/ksh.
 
Presumably you're trying to do something seriously funky then?

> What's really sad is that I think most of the people chose csh because they
> wanted to use switch,  and didn't know (or understand) case in sh.
 
I use *csh because the bourne-shell family syntax is often obtuse, frequently
arcane, and regularly abused.  By the time I *need* the capabilities of sh,
I'm already past the point of wanting to use a language like sh or csh.

Aside from case-based programs; then I go to sh.

> We actually want to try to get all their wrappers re-written, with one uber
> wrapper in perl (since the vast majority of the wrappers do a lot of the 
> same stuff), or basically an uber module that shorter perl, per-tool wrappers 
> would use for the basics.

When I hit the wall in csh, I look to perl, TCL, or a compiled language.
:)

> >Well, that's what you get for using colored paths.
> 
> Nah..

*sigh*

Another joke gone wide.

>       it's what we get due to everyone doing:
> set path=( $path <some paths> . )

And not "set -f path = ( $path <other paths> )" like they should?

(If you have users using bash, then they should be using tcsh, no?)

> all the time.. yes, they just about _all_ use . in their paths.. even after 
> we warn them.  

Users like . in their path.  I've trained myself out of needing .,
mostly by making ./ a usual prefix.... :)

>           This was why one of the past sysadmins wrote a program called
> envmgr ages ago... cool little program that removes duplicates in env 
> variables and prints out the syntax you need to set a variable.

I wrote a little ObjC program to remove duplicates from PATH-type
variables, as an exercise in ObjC.

> i.e.
> rs-workstation linux {553}$ envmgr -a PATH /bin
> PATH=/pkg/qct/sunray/bin:/usr/bin:/usr/ucb:/usr/afsws/bin:/usr/openwin/bin:/usr/dt/bin:/bin:/usr/local/bin:/usr2/mmarion/bin:/usr/local/sbin:/usr/sbin:/sbin:/pkg/icetools/bin:/usr2/mmarion/pkg/bin:/pkg/ice/sysadmin/bin:/opt/gnome/bin:/usr/X11R6/bin:/pkg/qct/software/bin:/pkg/qct/software/perl/bin;
> export PATH

Presumably it looked at $SHELL to generate the appropriate syntax?

> with swithces like -a to add, -p to prepend, -r to remove.. etc.  you 
> just call
> it with:
> eval `envmgr <stuff>`
> and it helps keep things clean.  I got so used to it that I use it at 
> home too.

So it does what? Look at an environment variable, treat it as a path,
and then prepends/removes/whatnot elements from that path, and then
output something to set that variable to the adjusted value?

> One of these days I'll see if he ever released it, or if we can.. nothing
> QC-oriented in it AFAIK.  Of course, one could script up something similar
> anyway.

A script implementation just sounds hairy. <shudder>

> We try to use envmgr in any scripts we write (and for things like package
> subscriptions.. don't ask) to keep people's env's as clean as we can.
 
How often is it really needed? I mean, it would be reallying annoying 
to read:

eval `envmgr -r foo bar`

instead of 

foo=bar

:)

> >I'd suggest that *all* bash or tcsh scripts be thrown out -- if you
> >can't write it in sh, csh, or ksh, use perl or tcl instead.
> 
> Well for linux scripts, considering that bash is usually the defacto 
> standard shell anymore... I don't see using bash there an issue.

I see as it a sign of arrogance. It's basically forcing people to use
bash even if they don't use it for anything themselves, don't want it,
and have no other need for it.  A sizable chunk of the Linux community
has imported the Microsoft attitude and it annoys me.... "All the world
is how we say, so you should just suck it up."

I'm tempted to roll a distribution built entirely with tcsh for scripting, 
and another on Tcl.  But that's a LOT of work.

-Stewart "Yet Another Item For My Little List" Stremler
-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to