Re: 'fg'ing a PID

Reid Ellis (
Tue, 27 Jul 1999 22:58:01 -0400

> > $ rc5des > output 2>&1 &
> That really works like a treat. What would be usefull for me is if you
> could explain what each element of the statement means and is doing.


$ -- the prompt :-)
rc5des -- the command [arguments can go after, like 'rc5des -flag -option 23'
> -- instead of printing output to the terminal send it to...
output -- name of file to which output is to be sent
2> -- instead of printing errors to the terminal send it to...
&1 -- the same place as the output

This has to do with a Unix convention for what are called "file descriptors"
-- simple small numbers of open files. File #1 is always "standard output",
which usually goes to your terminal. File #2 is always "standard error",
which usually also goes to your terminal. In fact, I think you can change the
">" up there to "1>" and it means the exact same thing. ">" is just a
shortcut name for "1>".

You know when you do some command, try to redirect to 'less' [or 'more' if you
don't know about 'less'], and some error messages print out before less starts
showing the output? Say you did something like this:

$ some_command | less

and you got this symptom. Well, you can fix it by doing this:

$ some_command | less 2>&1

now your error messages show up in 'less'. If you are a csh user, you can do
this instead:

% some_command |& less

Note that in ash/bash/ksh/sh you can do this:

$ some_command > output 2> errors

whereas a csh/tcsh user would have a harder time doing the same thing:

% (some_command > output) >& errors

Just to be clear, having a '&' at the end has nothing to do with using '>',
'2>', or '>&'.

Reid, your heplful shell tutor. :-)

Reid Ellis    <>
MGI Software  <>

This archive was generated by hypermail 2.0b3 on Sat Jul 31 1999 - 11:30:08 MDT