View Single Post
  #4 (permalink)  
Old 12-04-2004
Perderabo's Avatar
Perderabo Perderabo is offline
Unix Daemon
 

Join Date: Aug 2001
Location: Washington DC Area
Posts: 8,204
The trouble is that exec can do several different things...it really needs to be several commands. The code you gave won't work. Change that to
exec $fd < inputfile
and it probably will. But that is not what's meant by an fd.

A fd is always an integer. In shell scripts, it will be a very low integer. By convention:
0 = standard input
1 = standard output
2 = standard error output

The idea is that you write your program to output to fd 1 without knowing what fd one is. Then at execution time you can do stuff like:
echo this > first.file
echo that > second.file

It would be terrible if echo always sent stuff to "first.file". You would need to do:
echo that
cp first.file second.file
or something like that.

By default 0 1 2 are all connected to /dev/tty so you can type input to a program and see the results in your window.

Here is an experiment I just did:
$ expr 1 + 2
3
$ expr 1 + 2 > expr.out
$ cat expr.out
3
$ expr cat + dog > expr.out
expr: non-numeric argument
$

With the last expr command, I have an error. Since the error goes to 2 which is still /dev/tty, I see it immediately, even though the standard which is 1 goes to a file. That why we have both 1 and 2. You can send 1 into a file while 2 is still displayed to you.

Don't want to see error messages? Bad idea usually, but you can do:
expr cat + dog > expr.out 2>/dev/null

And now error messages are thrown away.

expr cat + dog > expr.out
really means
expr cat + dog 1> expr.out
but if you leave the integer off, 1 is assumed for > while 0 is assumed for <
Reply With Quote