Hi all, I've been following this list for about five years, and I don't
recall this subject having been raised before (though I did make some
comments on this general area -- consistency of return values -- a
couple of years ago). I mention this in the hope that solution 1 (make
$? work, delete reference in perlvms.pod to $^S, and document $?
emphatically) will be adopted. I searched all of my perl code, FWIW
(probably about 25k lines) and found only 2 references to $^S, and both
of those were written in the last couple of years, and never gave any
useful info...
So, I vote for option 1.
Carl
-----Original Message-----
From: Craig A. Berry [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 12:37 AM
To: Charles Bailey
Cc: [EMAIL PROTECTED]
Subject: Re: what the heck is $^S (was Re: waitpid return status)
At 6:08 PM -0400 6/3/01, Charles Bailey wrote:
>Craig A. Berry <[EMAIL PROTECTED]> wrote:
>>
>> I see the following with both 5.6.1 and bleadperl:
>>
> > $ perl -e "$pid=open(F, qq/|blechh/); waitpid($pid,0); print qq/**
$^S **/;"
>> %DCL-W-IVVERB, unrecognized command verb - check validity and
spelling
>> %DCL-W-IVVERB, unrecognized command verb - check validity and
spelling
>> \BLECHH\
>> \BLECHH\
>> ** **
>>
>> So yes it's blank as Tony reports. With 5.5.3 I sometimes see a
>> value of "0" for $^S but it usually hangs before it gets there.
>> Since zero is not a valid VMS status, it doesn't look like it worked
>> as documented back then either, so I'm wondering if this is something
> > that just never got implemented.
>
>Sigh; looks like it's broken. IIRC, the then-pumpking (Chip
Salzenberg)
>rewrote the subprocess status code in 5.004 to return a POSIXish status
by
>default, on the grounds of increased portability. The "vmsish status"
pragma
>and $^S were supposed to allow one to work around this, since the
POSIXish
>notion of status values doesn't map very well to non-Unix OSs. It's
>possible that the basic $^S-interpreting code (in mg.c, part of
>magic_get(), IIRC, but the guts are really in a macro defined in
perl.h)
>is addled; does it return a meaningful value if you invoke C<use vmsish
>qw(status)>?
Nope, no difference:
$ perl -e "use vmsish status; $pid=open(F, qq/|blechh/);
waitpid($pid,0); print qq/** $^S **/;"
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\BLECHH\
\BLECHH\
** **
and I don't see any VMS-specific stuff in the relevant part of mg.c from
5.6.1:
----cut from mg.c---------
case '\023': /* ^S */
{
if (PL_lex_state != LEX_NOTPARSING)
(void)SvOK_off(sv);
else if (PL_in_eval)
sv_setiv(sv, PL_in_eval & ~(EVAL_INREQUIRE));
}
break;
-------end of cut----------
I grepped the source tree of 5.004 (the oldest Perl I could quickly
grab from CPAN) and the only references to $^S I could find at all
were in perlvms.pod and there was no "case '\023'" in the bit of mg.c
quoted above. I haven't taken the time to build it yet and see if
the VMS-specific behavior actually worked back then. I suspect a $^S
behavior was planned and possibly implemented on the VMS port for
reasons Charles B. explains, but that the variable name was later
coopted by the other platforms and our docs never caught up.
There is now (but wasn't in 5.004) a cryptic explanation of $^S in
perlvar.pod (quoted verbatim in Camel) and it's not really compatible
with what perlvms.pod says:
=item $^S
Current state of the interpreter. Undefined if parsing of the current
module/eval is not finished (may happen in $SIG{__DIE__} and
$SIG{__WARN__} handlers). True if inside an eval(), otherwise false.
So, what to do:
1.) Delete references to $^S in perlvms.pod and make sure the
combination of $? and 'use vmsish status' is properly documented.
This would obviously be the easiest and might simply be fessing up to
what is (and perhaps always was) the truth. It would also free us
from claiming to have a rogue behavior not described in Camel. It
would also, though, break existing code that depends on the perlvms.pod
documented behavior, assuming this did actually work at some point
and someone actually used it.
2.) Try to implement what perlvms.pod says. I can't think of any
reason to do this except to fix backward compatibility. That,
however, might be a good enough reason if this did actually work in
the past.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
