Path: utzoo!attcan!uunet!lll-winken!lll-tis!mordor!joyce!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: weird sh(1) behaviour
Message-ID: <231@quintus.UUCP>
Date: 2 Aug 88 23:37:25 GMT
References: <163@cstw01.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 23

In article <163@cstw01.UUCP> meulenbr@cst.UUCP () writes:
>I noticed a peculiarity in sh which causes me a lot of trouble.
>The commands:
>	sh file
>and
>	sh <file
>are NOT equivalent.
>If you do think so, create a file which contains the command 
>	rm core

It isn't the shell's fault.  The sensitive command is 'rm'.
rm(1) will print an error message iff >>its<< standard input
is a terminal.  To verify this, in a directory having no 'core' file, do
	</dev/tty  rm core	# produces an error message
	</dev/null rm core	# is silent

If your script contains the line
	</dev/tty rm core
then both "sh script" and "sh <script" will produce the error message.

This is known and intended behaviour of the BSD /bin/rm; it doesn't
happen under V.3.  However, doing
	</dev/null rm file...
is harmless in V.3