Uri Guttman said:
>>>>>> "GL" == Greg London <[EMAIL PROTECTED]> writes:
>
> GL> system('cvs update -rtagname')
> GL> breaks this when the tagname doesn't exist.
> GL> perdoc -q control-c doesn't say any particular
> GL> bit is used to flag control-c, but the cvs command
> GL> set bit 1, while a control-c during a cp -r
> GL> command set bit 2.
>
> what bits? the signal part is a number (0-31) in a single byte and the
> exit code (another single byte) is in the other byte.
I was thinking maybe a particular bit in ($? & ff)
was a "control-c flag" bit.
> GL> If I just test bit 2 rather than 7..0,
> GL> would that still trap all the control-c's
> GL> but let all the commands that failed on their own
> GL> to keep running?
>
> >> if ($? & 0xff) {
> >> die "Process killed by signal ".($? & 0xff);
> >> } elsif ($? >> 8) {
> >> die "Process exited with status ".($? >> 8);
> >> } else {
> >> # Worked fine
> >> }
>
> are you using that code (or basing on it)? extract out both bytes and
> print them as integers and see what you get.
That was the problem. I cut and paste the code exactly
and didn't take a minute to look at it.
The elsif($?>>8) part should warn, not die.
I didn't notice the error message said "exited" rather than "killed"
and thought it was a signal from cvs-update, rather than an error
exit code.
The script takes about 20 minutes to run,
and in a panic, I sent the email saying it didn't work.
It works. I just needed to warn instead of die on non-zero exit codes.
The script is running now. And I think it's past the point where it
died before.
so, all is well, with the exception of slight brain fry on my part.
Greg
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
