Re: Honoring a command

[DervishD <raul@pleyades.net>]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> } The number of beers I owe you is growing dangerously ;)
> Especially considering that I rarely drink beer.  Send me a six-pack of
> some unusual Spanish soft drink, or something. ;-}

    I think the only soft drinks we have in Spain are from abroad,
but I'll take a look ;))
   
> }     alias scriptinit=$'emulate -L zsh ; trap \'return $LINENO\' ZERR'
> An interesting tidbit I just noticed -- if you read the script with the
> "source" or "." commands, $LINENO is reset to 1 when the trap runs, so
> you don't get as useful a return value.

    I know, but I never source that scrips (is there any way to make
a script as 'unsourceable' :?). This ZERR thing for returning an
error code is not very solid :( I should work in a better one, but I
had never the need O:)

> }     { whatever.command 2> /dev/null || print "Error message";false}
> Actually that won't work either, because that _always_ executes "false".
> I think you meant
>   { whatever.command 2> /dev/null || { print "Error message";false } }

    Yes, I forgot the braces, sorry O:)
 
> } but then 'verbosely_watch' has no purpose at all!
> You could write another little function:
>     verbosely_fail() {
> 	local ret=$?
> 	[[ -p /dev/fd/1 ]] && print "$*"
> 	return ret
>     }

    That's nice :)
> 
> Now this works:
> 
>   { whatever.command || verbosely_fail "Error message" } 2>/dev/null |
>   	verbosely_watch "Doing whatever"
> 
> If you DON'T pipe to verbosely_watch, then verbosely_fail is silent and the
> ZERR trap returns the line number as $?.  (Even if you do pipe it, the line
> number is stored in $pipestatus[1], which may be useful for other tricks.)
> 
> } I think I'd better use 'scriptinit' only for muted
> } scripts and verbosely_watch for the rest, using TRAPZERR for the
> } error message. Is that a good idea?
> That would work as well, but it means the error message is the same for
> every command (unless you re-assign it somehow each time).

    That's not a problem, I can use a global variable for the message
and reassign it before each command is run, instead of redefining
TRAPZERR (and obviously I must make TRAPZERR output that variable).

    Finally I think that the solution I'm going to adopt is the
function 'verbosely_watch', TRAPZERR for the error message instead
the OR list. I'm afraid that using ZERR to return the line number of
the error is only useful for debugging, to know where a bug happened,
but for production scripts I think is better to have a reduced and
well defined set of error return codes.

    Thanks a lot for your, as always, invaluable help.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/