catch exec #@$%@!
Anthony Johnson
There are dozens of commands that output stderr as warning or status
messages. The command exits with return code 0, but catch returns 1.
Does anyone else assume that stderr output means the command failed?
2) Is the message "child process exited abnormally" of any use to
anyone? An exit code (return code) is just that, and does not always
indicate a failure. I have many programs that look to certain exit codes
for specific meaning, and 'catch' always adds this message to my output
which screws up my data.
For example:
catch {exec diff $file1 $file2} result
always returns 1 if the files are different (this is NOT an error), and
the output of the command contains the lines I expect along with the
"child process exited abnormally" which I have to strip off.
I just can't think of any reason that having these 2 "features" are
useful in any way. Unfortunatly, I'm forced to use catch because without
it any non-zero return codes of commands causes the entire TCL script to
fail.
Paul Duffin
It is not [catch] but [exec] which assumes that if a process outputs on
stderr, or has a non-zero exit code then an error has occured. [catch]
just simply catches the error generated by [exec] and tells you about it.
This assumption of [exec] is actually quite a reasonable one as *most*
Unix executables use 0 exit code as success and a non-zero exit code for
error, and most log errors to stderr and normal output to stdout. The
fact that all of them don't is unfortunate.
The "child process exited abnormally" is a human readable piece of
information which IS quite useful to know. $errorCode contains more
useful information such as the actual error status.
[exec] could certainly be improved by adding some options to it, e.g.
-ignorestderr
-ignoreexitcode
-pipe [rw]
# As a replacement for [open "|..."] which has some
# marvellous quoting problems when things have spaces
# inside.
--
# End of options
Why not have a go at modifying [exec] to do what you want ?
Frederic BONNET
Anthony Johnson wrote:
>
> 1) Why does catch always assume that stderr of a command is an error?
> There are dozens of commands that output stderr as warning or status
> messages. The command exits with return code 0, but catch returns 1.
> Does anyone else assume that stderr output means the command failed?
>
> 2) Is the message "child process exited abnormally" of any use to
> anyone? An exit code (return code) is just that, and does not always
> indicate a failure. I have many programs that look to certain exit codes
> for specific meaning, and 'catch' always adds this message to my output
> which screws up my data.
> For example:
> catch {exec diff $file1 $file2} result
> always returns 1 if the files are different (this is NOT an error), and
> the output of the command contains the lines I expect along with the
> "child process exited abnormally" which I have to strip off.
>
> I just can't think of any reason that having these 2 "features" are
> useful in any way. Unfortunatly, I'm forced to use catch because without
> it any non-zero return codes of commands causes the entire TCL script to
> fail.
I believe the problem is with exec, not catch. Catch is rather dummy in the
sense that it only looks at the command's return code and result. In this case,
exec is guilty of adding extra messages (ie "child process exited abnormally")
or treating stderr output as errors.
More exactly (after digging into the Tcl source), it seems that these errors
come from pipe channel handling. Maybe you could post a RFE in order to correct
these "features". For example, adding flags to exec.
See you, Fred
--
Frédéric BONNET frederi...@free.fr
(please note my new email adresss ^^^^^^^^^^^^^^^^^^^^^^
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain
laurent....@uforce.com
>
> Anthony Johnson wrote:
>>
>> 1) Why does catch always assume that stderr of a command is an error?
>> There are dozens of commands that output stderr as warning or status
>> messages. The command exits with return code 0, but catch returns 1.
>> Does anyone else assume that stderr output means the command failed?
>>
>> 2) Is the message "child process exited abnormally" of any use to
>> anyone? An exit code (return code) is just that, and does not always
>> indicate a failure. I have many programs that look to certain exit codes
>> for specific meaning, and 'catch' always adds this message to my output
>> which screws up my data.
>> For example:
>> catch {exec diff $file1 $file2} result
>> always returns 1 if the files are different (this is NOT an error), and
>> the output of the command contains the lines I expect along with the
>> "child process exited abnormally" which I have to strip off.
>>
I've got the same beef about exec.
> This assumption of [exec] is actually quite a reasonable one as *most*
> Unix executables use 0 exit code as success and a non-zero exit code for
> error, and most log errors to stderr and normal output to stdout. The
> fact that all of them don't is unfortunate.
>
Yeah but it's unfortunate that Tcl doesn't give you an easy way to get
around buggy program implementations.
> [exec] could certainly be improved by adding some options to it, e.g.
> -ignorestderr
> -ignoreexitcode
> -pipe [rw]
> # As a replacement for [open "|..."] which has some
> # marvellous quoting problems when things have spaces
> # inside.
> --
> # End of options
>
Yeah! Yeah!
> Why not have a go at modifying [exec] to do what you want ?
>
Oh!.... (Turns around slowly, looking over his shoulder[*])
L
[*] Not that I can't do it. But there's just not enough time in a day, too
mucxh Real Work in said day, and too many babies to take care of in the
evening. :-)
--
Laurent Duperval "Montreal winters are an intelligence test,
mailto:laurent....@uforce.com and we who are here have failed it."
-Doug Camilli
Penguin Power! ***Nothing I say reflects the views of my employer***
km...@socrates.berkeley.edu
Anthony Johnson <ant...@storix.net> wrote:
>1) Why does catch always assume that stderr of a command is an error?
>There are dozens of commands that output stderr as warning or status
>messages. The command exits with return code 0, but catch returns 1.
>Does anyone else assume that stderr output means the command failed?
The easiest way to get around this (mis) feature is to do:
exec cmd 2>@stderr
This simplies redirects stderr back to itself but
the redirection turns off considering it an error.
Keith
Jeffrey Hobbs
> 1) Why does catch always assume that stderr of a command is an error?
> There are dozens of commands that output stderr as warning or status
> messages. The command exits with return code 0, but catch returns 1.
> Does anyone else assume that stderr output means the command failed?
Yes, this is a de facto way to mean that an error likely occured.
That is, after all, why it is the standard *error* channel.
Unfortunately, since you only get stdout and stderr by default,
many programs do use it to allow for separatable output.
BTW, it's exec that throws the error, not catch (that just
catches it).
> 2) Is the message "child process exited abnormally" of any use to
It's used in several cases, for example where the program also
returned a non-zero exit status (also correctly assumed to be an
abnormal exit, or error). There may be no output, so the message
is added.
--
Jeffrey Hobbs The Tcl Guy
hobbs at ajubasolutions.com Ajuba Solutions (née Scriptics)
Anthony Johnson
> Anthony Johnson wrote:
> >
> > 1) Why does catch always assume that stderr of a command is an error?
> > There are dozens of commands that output stderr as warning or status
> > messages. The command exits with return code 0, but catch returns 1.
> > Does anyone else assume that stderr output means the command failed?
> >
> > 2) Is the message "child process exited abnormally" of any use to
> > anyone? An exit code (return code) is just that, and does not always
> > indicate a failure. I have many programs that look to certain exit codes
> > for specific meaning, and 'catch' always adds this message to my output
> > which screws up my data.
> > For example:
> > catch {exec diff $file1 $file2} result
> > always returns 1 if the files are different (this is NOT an error), and
> > the output of the command contains the lines I expect along with the
> > "child process exited abnormally" which I have to strip off.
> >
> > I just can't think of any reason that having these 2 "features" are
> > useful in any way. Unfortunatly, I'm forced to use catch because without
> > it any non-zero return codes of commands causes the entire TCL script to
> > fail.
>
> It is not [catch] but [exec] which assumes that if a process outputs on
> stderr, or has a non-zero exit code then an error has occured. [catch]
> just simply catches the error generated by [exec] and tells you about it.
If the program is designed to exit 1 and return no data (as with diff, grep,
cut and many other typical UNIX tools), then I see no value in having exec
change the output. Does anyone actually want exec to change the output of the
command? It's difficult to strip out the unwanted message and make use of the
actual return code using exec, particularly when there are numerous commands
in a pipe, so I've ended up in many cases just calling a Korn shell script
instead that runs the command, handles the return code and the output (or lack
thereof) as they were intended, then always makes sure to exit 0 so exec
doesn't change anything.
> This assumption of [exec] is actually quite a reasonable one as *most*
> Unix executables use 0 exit code as success and a non-zero exit code for
> error, and most log errors to stderr and normal output to stdout. The
> fact that all of them don't is unfortunate.
Doesnt seem so reasonable to me. Silly assumption that any one of 255
different possible return codes all mean nothing more than "child process
exited abnormally".
> The "child process exited abnormally" is a human readable piece of
> information which IS quite useful to know. $errorCode contains more
> useful information such as the actual error status.
>
> [exec] could certainly be improved by adding some options to it, e.g.
> -ignorestderr
> -ignoreexitcode
> -pipe [rw]
> # As a replacement for [open "|..."] which has some
> # marvellous quoting problems when things have spaces
> # inside.
> --
> # End of options
Well, I dont want to necessarily ignore stderr, just dont want to assume it
means the command failed. I know I can use open, fileevent, pipes, etc to do
what I want but catch/exec takes about 50 lines of code to do what Ksh can do
in:
command 2>&1 | read output
print rc=$?
> Why not have a go at modifying [exec] to do what you want ?
Love to but I dont want to be in the business of writing a new shell. I really
only use TCL because of Tk. I'll just continue to use Ksh for other things
mainly because it's more UNIX-like and predictable. I don't mean to just blow
wind here - was hoping someone shared my grief and could offer a better
solution.
Neil Madden
Jeffrey Hobbs wrote:
>
> Anthony Johnson wrote:
> > 1) Why does catch always assume that stderr of a command is an error?
> > There are dozens of commands that output stderr as warning or status
> > messages. The command exits with return code 0, but catch returns 1.
> > Does anyone else assume that stderr output means the command failed?
>
> Yes, this is a de facto way to mean that an error likely occured.
> That is, after all, why it is the standard *error* channel.
> Unfortunately, since you only get stdout and stderr by default,
> many programs do use it to allow for separatable output.
> BTW, it's exec that throws the error, not catch (that just
> catches it).
>
> > 2) Is the message "child process exited abnormally" of any use to
>
> It's used in several cases, for example where the program also
> returned a non-zero exit status (also correctly assumed to be an
> abnormal exit, or error). There may be no output, so the message
> is added.
Couldn't you just add the message _if_ there is no output? That would
seem to be better.
lvi...@cas.org
:> > 2) Is the message "child process exited abnormally" of any use to
:> > anyone? An exit code (return code) is just that, and does not always
:> > indicate a failure.
For that matter, why put out the msg at all? Why not just return a value
that indicates a problem and let the application do something about it?
It is just as easy to let someone check a return code and put their own
message - one frankly that will be more likely to be accurate, that it
is to have many people reproduce code that prevents that msg when it in
fact is wrong.
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Donal K. Fellows
Paul Duffin <pdu...@hursley.ibm.com> wrote:
> -pipe [rw]
> # As a replacement for [open "|..."] which has some
> # marvellous quoting problems when things have spaces
> # inside.
What's wrong with:
open |[list ...] r+
That handles all awkward cases perfectly...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- I may seem more arrogant, but I think that's just because you didn't
realize how arrogant I was before. :^)
-- Jeffrey Hobbs <jeffre...@scriptics.com>
Cameron Laird
Anthony Johnson <ant...@storix.net> wrote:
.
.
.
>Well, I dont want to necessarily ignore stderr, just dont want to assume it
>means the command failed. I know I can use open, fileevent, pipes, etc to do
>what I want but catch/exec takes about 50 lines of code to do what Ksh can do
>in:
> command 2>&1 | read output
> print rc=$?
.
.
Did Keith Mead's follow-up not arrive at your host? His
remark <URL:http://www.deja.com/getdoc.xp?AN=637263105>
about
exec cmd 2>@stderr
completely answers your demand, if I understand it
correctly.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Anthony Johnson
catch {exec diff file1 file2} result
is the same as
catch {exec diff file1 file2 2>@stderr} result
Assuming file1 and file2 differ, result is the differences along with "child
process exited abnormally" at the end.
Glenn W Jackman
>Thanks, but I tried this and it made no difference:
> catch {exec diff file1 file2} result
>is the same as
> catch {exec diff file1 file2 2>@stderr} result
>
>Assuming file1 and file2 differ, result is the differences along with "child
>process exited abnormally" at the end.
If I understand correctly, the return code for diff is non-zero here, so
this "trick" does not really apply. Redirecting stderr to itself is to
handle exec complaining because it detected output on stderr when the actual
return code from the command is zero.
-glenn