weird sh(1) behaviour

[Randal L. Schwartz @ Stonehenge]

In article <163 at cstw01.UUCP>, meulenbr at cstw01 (Frans Meulenbroeks) writes:
| [I posted this before to comp.unix.questions but got no reply;
|  hopefully some wizard can help me]
| 
| 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.
| 
| I've played with the options of sh, but to no avail.
| Can somebody explain this behaviour to me, and tell me how I can 
| communicate through popen with the (a) shell, without losing my error
| messages.

The problem is not sh(1), but rm(1).  Try:

  rm core

vs.

  rm core </dev/null

to see the difference.  rm(1) is checking stdin to see if it needs to
bitch.  This is true of a few other commands as well, but the exact
list escapes me.  sh doesn't really care (well, almost :-).  Another
difference between your two invocations is the matter of additional
parameters.  Notice the difference between:

  sh file arg1 arg2 arg3

and

  sh <file arg1 arg2 arg3

The first sets $1 to arg1, $2 to arg2, and so on.  The second
(attempts to) execute arg1 as a shell script, with $1 set to arg2, $2
set to arg3, and stdin set to file!
-- 
Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095
on contract to BiiN Technical Publications (for now :-), Hillsboro, Oregon
<merlyn at intelob.intel.com> or ...!tektronix!ogcvax!omepd!intelob!merlyn
Standard disclaimer: I *am* my employer!