Path: utzoo!utgpu!attcan!uunet!mcvax!hp4nl!mhres!hd
From: hd@mh_co2.mh.nl (Theo Hardendood)
Newsgroups: comp.unix.wizards
Subject: Re: weird sh(1) behaviour
Message-ID: <2184@mhres.mh.nl>
Date: 3 Aug 88 00:13:09 GMT
References: <163@cstw01.UUCP>
Sender: news@mhres.mh.nl
Lines: 42

From article <163@cstw01.UUCP>, by meulenbr@cstw01.UUCP (Frans Meulenbroeks):
> 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
> Try both versions in a dir without a file named core.
> sh file will give you an error message "No such file...", while
> sh <file won't.
> The same holds when sh is used in a pipe.

Not sh but rm does his job this way. If the standard input is not a
terminal, then no diagnostics are produced. This is certainly NOT a
bug and makes it possible, for example, to use rm in a crontab entry
without extensive checking.

The difference between 'sh file' and 'sh <file' is that 'sh file'
executes with your terminal as standard input and 'sh <file' doesn't.
To show you the problems that can occur, try the following script.
I think it works on most BSD systems but I didn't check (sorry).

-------------------------- Cut here ---------------------------------
read xx
echo -n 'Did you expect this '
echo $xx
exit 0
This is a dirty way to read input.
------------ End of script (do not include this line) --------------

A way to avoid this problem is to include a line:
	exec </dev/tty
before the first read is done.

Note: The following code is invalid:
	read xx </dev/tty

Theo Hardendood                  hd@mh.nl via european backbone (mcvax)
Multihouse NV, Gouda - The Netherlands          uucp: ..!mcvax!mh.nl!hd
"A conclusion is simply the place where someone got tired of thinking."