weird sh(1) behaviour

[Theo Hardendood]

>From article <163 at cstw01.UUCP>, by meulenbr at 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 at 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."