(It seems like we were overdue for a new subject line.)
Chuck,
Thanks for allowing me to goad you into all this extra work :-).
Option 3 does sound like the cleanest. If it's the definition of
SYS$ERROR during image run-down that contradicts the rest of the
redirection scheme, then redefining the logical does seem like the
way to go. Unfortunately you'll have to use sys$crelnm with the 4th
argument set to PSL$C_USER to get a user-mode logical since
lib$set_logical doesn't do modes.
I take it this would go in getredirection(). Would you redefine the
logical for all 2> redirections, or only when the output is the
special &1 case?
At 8:40 AM -0500 12/1/00, lane @ DUPHY4.Physics.Drexel.Edu wrote:
>"Craig A. Berry" <[EMAIL PROTECTED]> writes:
>> ...it'd still be nice to find a way to
>> get a child process to leave the parent's SYS$ERROR alone when its own has
>> been redirected.
>
>The recent conniptions with the lib/filter-util test prompted me
>to take another look at how stderr is set up for subprocesses started
>by safe_popen (used for backtick and open(..,"stuff|") type commands,
>but not system()).
>
>Some background: lib$spawn always starts subprocesses with
>SYS$ERROR set to the same thing as SYS$OUTPUT. We use can have
>VMSPIPE.COM define SYS$ERROR to something else, and any "2>" on a Perl
>command line will redirect inside of Perl.
>
>So if we do a:
>
> $a = `perl blah.pl 2>&1`;
>
>then:
> At startup, the subprocess will have its SYS$OUTPUT directed to a
> mailbox (so we can read it into $a); its SYS$ERROR will point
> to the same mailbox ('cause that's what LIB$SPAWN does).
> VMSPIPE, as part of its "get ready to run Perl" will then define
> SYS$ERROR to whatever the parent process decided it should be;
> for proper "unixy" behavior, that means "inheriting the parents
> stderr", or rather pointing SYS$ERROR to the same place as the
> parents stderr is pointing.
> When the subprocess executes Perl, the command-line redirection does
> a dup2 to point the subprocesses stderr to its stdout, internal to
> Perl.
>
>Now, I think the forgoing gives correct "unixy" behavior, that is that
>child processes inherits the parent's current definition of stderr at
>the time when the child is spawned.
>
>The problem we've been seeing comes (at least partially) from the fact
>that the 2>&1 redirection only lasts as long as Perl is running; if
>Perl exits with an error status then the VMS message is printed by
>a DCL-established exit handler during the Perl image run down.
>
>You can see this just by doing a:
>
> $ perl -e"exit(44);" 2>ERRS.
> %SYSTEM-F-ABORT, abort
> $ type ERRS.
> $
>
>As can be seen, the VMSish error message goes to the original
>(pre-redirection) SYS$ERROR, rather than the file ERRS.
>
>As a result, we get %RMS-F-FNF stuff going back not via the
>command-line 2>&1 to get read by the parent, but to the definition of
>SYS$ERROR before Perl's command-line redirection, i.e., the one
>inherited from its parent, which likely points back to a grandparent
>or the like.
>
>And there's the problem. We'd like the Perl command line redirection,
>or whatever "open(STDERR,...)" commands are present in the script, to
>override the inheritance of stderr for VMSish error messages printed
>during Perl's rundown.
>
>Here's an attempt to figure out all the possible ways to address this:
>
>1. Don't redirect SYS$ERROR away from SYS$OUTPUT, forget inheriting
> the parent's stderr.
>
> I'd prefer we didn't do this, since it actually is doing what it
> should; it's other misfeatures that are causing the problem. We'd
> be losing a useful feature.
>
>2. Put our own exit-handler in Perl to write VMS error messages during
> rundown, using the "Perl redirected" stderr. We'd have to supress
> the DCL-generated error message.
>
> I *think* this is feasbile, but the main downside is that we'd
> have to modify status values to get DCL to supress its own
> messages (i.e., set the "masking bit" in the high-order status
> value). So if you exit(0x2C) from Perl, the DCL $STATUS symbol
> would get something like 0x1000002C. Kinda ugly.
>
>3. When we do command-line redirection of stderr (or opening STDERR
> from Perl?), we also redefine the logical SYS$ERROR so that DCL's
> exit handler will write to the correct place.
>
> This option might well be a winner... a bit of testing with
> define/user shows that it does indeed redirect the DCL messages,
> (i.e., the logical persists just long enough) and a "user-mode"
> definition doesn't stick around to mess up later commands.
>
> Doing this for the command-line redirection is simple; I'm not
> sure yet how much of a problem it is for doing open(STDERR,...)
> in a Perl script.
>
>4. Have safe_popen try to pre-parse the command line, looking for
> "2>..." stderr redirections, and get them in place before Perl
> runs.
>
> I don't want to go there....
>
>Comments and suggestions are welcome, as always. I'll see if I can
>whip up a simple fix for the command-line redirection based on option #3,
>but hold off on dealing with open(STDERR,...) until there's some feedback.
>--
> Drexel University \V --Chuck Lane
>======]---------->--------*------------<-------[===========
> (215) 895-1545 _/ \ Particle Physics
>FAX: (215) 895-5934 /\ /~~~~~~~~~~~ [EMAIL PROTECTED]
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
