Tcl - Removing leading `/' from member names

Author

Removing leading `/' from member names

Eric Tetz

2004-08-27, 8:57 pm

I'm trying to use tar from TCL. I create an archive successfully, but tar writes
the following to stderr:

"Removing leading `/' from member names"

In TCL, if a spawned process writes to stderr it is considered an error, so my
script aborts.

I could:
1) Use the -P option in tar to store the leading '/'.
2) Catch errors from tar and ignore them.
3) Parse error output from tar and ignore that specific message.

None of these are appealing options -- does anyone know of any others? Does
anyone know why TCL is reporting deliberate, documented behavior as an error?

Cheers,
Eric

Don Porter

2004-08-27, 8:57 pm

Eric Tetz wrote:
> None of these are appealing options -- does anyone know of any others?

Redirect stderr so that writes to it don't reach Tcl to be detected
as an error.

> Does anyone know why TCL is reporting deliberate, documented behavior
> as an error?

Because Tcl cannot read and follow the instruction manual of every
program it can [exec] ?

If programs ignore conventions and use stderr to report conditions
that are not, in fact, errors, you can't blame Tcl for that.

Instead the programmer has to read those manuals, and work around
the problem with a stderr redirect.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|

Eric Tetz

2004-08-27, 8:57 pm

Don Porter wrote:
> Eric Tetz wrote:
>
> Redirect stderr so that writes to it don't reach Tcl to be
> detected as an error.

That was one of the unappealing options I listed. It means
parsing tar's "error" output in my script so I can distinguish
between this non-error and a *real* error that I don't want
to ignore. Total kludge.

>
> Because Tcl cannot read and follow the instruction manual
> of every program it can [exec] ?

I mean to say "tar". Why does *tar* report well-defined,
default behavior as an error? As a matter of fact, I meant to
post this to the tar newsgroup. See what sleep deprevation
does to you? ;)

Cheers,
Eric

Donald Arseneau

2004-08-28, 3:57 am

"Eric Tetz" <erictetz@y-a-h-o-o.com> writes:

> I mean to say "tar". Why does *tar* report well-defined,
> default behavior as an error?

It doesn't. It reports a message on the output channel that
is meant for errors...and warnings and other status.
It should *not* report the warning mixed in with the program
output (which can be the tar archive).

> As a matter of fact, I meant to
> post this to the tar newsgroup. See what sleep deprevation
> does to you? ;)

You did well. It is a Tcl problem that bugs me too. Mere
output on the stderr channel should *not* trigger an error
return by exec.

I suggest you use blt's bgexec which is better than exec.

Donald Arseneau asnd@triumf.ca

Ralf Fassel

2004-08-28, 8:56 pm

* "Eric Tetz" <erictetz@y-a-h-o-o.com>
| That was one of the unappealing options I listed. It means parsing
| tar's "error" output in my script so I can distinguish between this
| non-error and a *real* error that I don't want to ignore. Total
| kludge.

When closing the channel, you get the exit status of the program as
additional info (lindex $::errorCode 0 and 2). Only if that is not
NONE/0, check the stderr output.

% catch {exec sh -c false}
1
% set errorCode
CHILDSTATUS 1851 1
% catch {exec sh -c {echo >&2}}
1
% set errorCode
NONE

I assume that tar does a better job with the exit status, at least
this has been my experience.

R'

Sponsored Links