Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!csustan!csun!aeusesef
From: aeusesef@csun.UUCP (sean fagan)
Newsgroups: comp.bugs.sys5
Subject: Re: sh bug
Message-ID: <856@csun.UUCP>
Date: Tue, 27-Oct-87 20:53:33 EST
Article-I.D.: csun.856
Posted: Tue Oct 27 20:53:33 1987
Date-Received: Sat, 31-Oct-87 03:45:26 EST
References: <467@virginia.acc.virginia.edu>
Reply-To: aeusesef@csun.UUCP (Sean Eric Fagan)
Organization: California State University, Northridge
Lines: 25

In article <467@virginia.acc.virginia.edu> mer6g@virginia.UUCP (Marc Rouleau) writes:
>On our 3b2, 3b5, and 3b15 AT&T systems running SYSV.2 and SYSV.3, sh does
>something rather unfortunate when certain built-in functions fail.  For
>example,
>
>	cd nowhere || echo 'cd failure'
>
>where ``nowhere'' is nonexistent does not (as you might expect) cause ``cd
>failure'' to be echoed to the screen.  The expected error message is produced
>and then . . . nothing, a new prompt.
I think that the problem is that cd is a shell built-in, and one of the few
(possibly only?) that doesn't get checked for a return value.  This is a
definitely a bug.  And, as you remark below, it is fixed in Korn Shell.
Fixes would be appreciated here, too.
>BTW, ksh handles all this stuff correctly.

>Marc Rouleau		University of Virginia      Academic Computing Center
>mer6g@virginia.edu	mer6g@virginia [bitnet]	    	    ...virginia!mer6g

 -----

 Sean Eric Fagan          Office of Computing/Communications Resources
 (213) 852 5742           Suite 2600
 1GTLSEF@CALSTATE.BITNET  5670 Wilshire Boulevard
                          Los Angeles, CA 90036
{litvax, rdlvax, psivax, hplabs, ihnp4}!csun!aeusesef