Q: "remsh" - Korn shell vs C-shell
John Emmerling
We have some scripts that were originally written in C-shell.
When HP-UX was upgraded to 10.20, these scripts stopped
working, however when modified to use TCSH, the same
scripts still run.
Because we can't assume that users have TCSH or where
it is installed (e.g. it can be /usr/local/bin/tcsh or /usr/bin/tcsh),
I decided to try translating the scripts to Korn Shell.
There is one script in particular which must be invoked with a remsh.
The syntax currently used is
"remsh <hostname> -n 'sh -c "<full path to script> <script params> 1>&-
2>&- &"'
Note: "remsh" is equivalent to "rsh" on some unices.
This is straight from the remsh man page. It worked if the script was in
TCSH
(and for C-shell scripts under HP-UX 9.05). However when the same script
is in Korn Shell it fails. I tried invoking the script interactively the
same way
and it dies. I think it has something to do with how Korn Shell scripts
deal with
standard input and output when running in the background.
I changed the invocation to end with " 1>/dev/null 2>&1 &".
This seems to work, however I am nervous that it is somehow risky to
explicitly redirect output to the null device (is it?).
Marty Duffy
I been usin the korn shell for 10 years, and I have found that redirecting
standard out and standard error to /dev/null is an effective way to deal
with output I don't want.
Marty Duffy
mdu...@bigfoot.com
John Emmerling wrote in message <01bd0975$2dfde700$7d1456c0@c-104638>...
Mark Mraz
John Emmerling wrote:
> I changed the invocation to end with " 1>/dev/null 2>&1 &".
> This seems to work, however I am nervous that it is somehow risky to
> explicitly redirect output to the null device (is it?).
I know of nothing "risky" about it. In fact, I would recommend it.
Here's why. Suppose you run a program that opens a file. The first
available file descriptor is 1 (i.e. standard output), so it uses it.
Now suppose that, while this file is open, it writes a diagnostic
message to standard output (echo in a shell script, printf in a C
program). You now have garbage in your file.
Also, although unlikely, it is possible that a program could check its
writes to standard output or standard error, and fail if they are
closed. They wouldn't fail if they were redirected to /dev/null.
So, I would say that unless you are sure that all the commands you
will use don't create output, it's probably a bad idea to close standard
input, output, and error. Redirect them to /dev/null, instead.
Mark
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/ Real Name: Mark Mraz \
\ Email Address: mm...@rpa.net /
/ Web Page: http://www2.rpa.net/~mmraz \
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Stephen Harris
John Emmerling (jemm...@cscmail.csc.com) wrote:
: I changed the invocation to end with " 1>/dev/null 2>&1 &".
: This seems to work, however I am nervous that it is somehow risky to
: explicitly redirect output to the null device (is it?).
Your changes are correct changes. Redirecting stdout/stderr to /dev/null in
this way is normal shell programming technique, and is the primary use of
/dev/null for shell programmers :-)
--
rgds
Stephen
Donn Cave
Just use it, don't abuse it, though.
When you /dev/null diagnostic output, all kinds of errors can go unnoticed.
It can make problems unnecessarily difficult to find and fix. If you're
trying to build a reliable system, it's a technique that has to be applied
with some thought. I've had to work on software whose authors preferred
to generally sweep problems under the rug by disabling diagnostic output.
It may even qualify as normal shell programming technique, but it's sure
not going to get any awards from me.
In this case, it sounds like we're trying to fix a problem that we don't
understand, having something to do with differences between tcsh and ksh.
If the software is important, it's probably worth trying to figure out
what's going on and fix the problem, rather than patch it with /dev/null.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
(A short example script that illustrates the problem would be a good start.)
Mark Conty
John Emmerling wrote:
[...]
> There is one script in particular which must be invoked with a remsh.
> The syntax currently used is
> "remsh <hostname> -n 'sh -c "<full path to script> <script params> 1>&-
> 2>&- &"'
> Note: "remsh" is equivalent to "rsh" on some unices.
> This seems to work, however I am nervous that it is somehow risky to
> explicitly redirect output to the null device (is it?).
[ I think some of you are missing the point. He's not asking about the
validity of routing output to /dev/null. The "1>&-" construct in fact
_does_ that. The way to fire off a remsh in the background and not have
the local copy hang (waiting for returning output) is to _close_
standard input, output, and error with the ">-" construct. ]
John, I'm puzzled that the redirecting to /dev/null works; I always
thought that the "official" way of spinning off backgrounded remsh's was
with the ">-" stuff. Otherwise, I'd expect it to not really _close_ the
input/output files until the process ends. (Maybe, in this context,
this does the same thing as redirecting the output into real files on
the remote host.)
What I want to know, though, is what you're seeing when it fails. I
mean, do you _know_ that the remsh'd command really works when you run
it manually and in the foreground on the remote host? Try that and see
what kind of output you get ... if you haven't already.
(BTW, you may also want to close the remote STDIN with "<&-"...)
Good luck!
--
Mark Conty mark_...@cargill.com (work)
Cargill Grain Division m...@isd.net (home)
CGD/LYNX Server Support <>< Phone: 612/984-0503
Mark Mraz
Mark Conty wrote:
> John, I'm puzzled that the redirecting to /dev/null works; I always
> thought that the "official" way of spinning off backgrounded remsh's was
> with the ">-" stuff. Otherwise, I'd expect it to not really _close_ the
> input/output files until the process ends. (Maybe, in this context,
> this does the same thing as redirecting the output into real files on
> the remote host.)
All the daemons I've written have always redirected standard input,
output, and error either to /dev/null or some log file. All that's
really necessary is to close all connections to the tty (or in this
case, the remsh socket). As I pointed out in a previous post, there can
actually be some unfortunate side-effects by closing these file
descriptors.
Stephen Harris
Donn Cave (do...@u.washington.edu) wrote:
: sw...@mpn.com (Stephen Harris) writes:
: | Your changes are correct changes. Redirecting stdout/stderr to /dev/null in
: | this way is normal shell programming technique, and is the primary use of
: | /dev/null for shell programmers :-)
: Just use it, don't abuse it, though.
Umm, I've heard that in other areas of life :-)
: When you /dev/null diagnostic output, all kinds of errors can go unnoticed.
: It can make problems unnecessarily difficult to find and fix. If you're
: trying to build a reliable system, it's a technique that has to be applied
: with some thought. I've had to work on software whose authors preferred
Any good shell program requires some thought :-)
: to generally sweep problems under the rug by disabling diagnostic output.
Ugh, that's not good. In general, you should only /dev/null diagnostic
output when you _know_ your code will test the return code, or the error
is unimportant (eg if using wildcards in potentially empty directories...)
for a in $(grep -l xyzzy * 2>/dev/null)
do
ugug
done
Fortunately, most the people I've had to deal with either (i) have no clue
about scripting, so I just replace their 50 line effort with a better 10
liner, or (ii) have had 5 years worth of kludges applied, so reverse
engineering and rewriting is the only sane method :-)
: It may even qualify as normal shell programming technique, but it's sure
: not going to get any awards from me.
Correctly used, it will from me.
But correctly used _rarely_ means the whole program should be /dev/null'd in
this way. The only reason it was suitable in this thread was because the
original non-working attempt closed stdio anyway.
--
rgds
Stephen