Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!rbj
From: rbj@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.lang.perl
Subject: Re: pwd?
Message-ID: <130316@uunet.UU.NET>
Date: 24 Apr 91 23:13:26 GMT
References: <1991Apr17.165554.16507@iwarp.intel.com> <129476@uunet.UU.NET> <1991Apr23.145850.6064@chinet.chi.il.us>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 37

In article <1991Apr23.145850.6064@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
?In article <129476@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
?
?>I have never seen a shell that treated cd properly with respect
?>to && and ||. Try "cd /bogon || echo failed".

What am I talking about? Both my ksh's do the right thing.

?The "proper" thing for any shell that offers to run /bin/sh scripts
?to do is to exit immediately with an error status when a cd fails.

Yeah, but I'd much rather see 'cd' return a status just like a command.
Since you quoted "proper", perhaps you do as well?

?Unfortunatly some don't, and more unfortunate there is no way to
?control it (i.e. IMHO as a sometimes useful extension there should
?be an option to enable it in a script that expects to continue past
?a cd).

That's what the -e option is for.

?As it is, all those historically correct shell scripts that
?cd somewhere ; rm -f * will happily eat your current directory when
?you replace /bin/sh with ksh and "somewhere" goes away.

Sometimes fixing bugs is dangerous.

?Anyway, just to maintain some relevance to perl - in the above case
?it doesn't matter much.
?
?Les Mikesell
?  les@chinet.chi.il.us


-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane