On Jul 20, 2014, at 2:52 PM, John Dite <john.d...@compinia.de> wrote:
> Hi,
>
> first of all thanks for all the replies.
>
> Either I don't understand or it doesn't make sense to me.
OK, let me try again.
> For example, with perl on Linux:
>
> $ perl -e "\$s='nosuchdir'; chdir \$s or die \"Can't cd to \$s: '\$!'\n\""
> Can't cd to nosuchdir: 'No such file or directory'
>
> $ echo $?
> 2
>
> $ perl -e "\$s=\$ENV{X} or die \"no such environment variable: '\$!'\n\""
> no such environment variable: ''
>
> $ echo $?
> 255
>
> $
> and "equivalent scripts" with perl on VMS:
>
> $ perl -e "$s='nosuchdir'; chdir $s or die ""Can't cd to $s: '$!, $^E'\n"""
> Can't cd to nosuchdir: 'no such file or directory, %RMS-E-DNF, directory
> not found'
> %SYSTEM-F-ABORT, abort
>
> $ sh symbol $status
>
> $STATUS == "%X0000002C"
> perl -e "$s=$ENV{X} or die ""no such environment
> variable: '$!, $^E'\n"""
> no such environment variable: 'invalid argument, %SYSTEM-F-NOLOGNAM, no
> logical name match'
> %SYSTEM-F-NOLOGNAM, no logical name match
>
> $ sho symbol $status
> $STATUS == "%X000001BC"
> $
What you've actually demonstrated here is that the behavior on Unix and VMS is
equivalent. A die after a failed syscall (such as chdir) causes a generic
failure status to be passed to the operating system when Perl exits. A die
under other circumstances (such as a failed lookup in %ENV, which is not a
syscall) causes an exit status to be concocted from errno or vaxc$errno or fall
back to some other generic value if errno is not set.
One difference on VMS is that it's no problem to pass a full 32-bit condition
value to the operating system, whereas on Unix there is various masking and
shifting going on to try to encode a meaningful status in 8 bits. I think in
your example, the 255 you see on Unix is a fallback for when errno is not set.
The details are at
<http://perl5.git.perl.org/perl.git/blob/maint-5.20:/perl.c#l4947>.
> and regarding
>
> 1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv
> implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is
> normal and as it should be.
>
> 2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the
> most recent value of vaxc$errno and uses it as the VMS exit status. This
> is also normal behaviour.
>
> In the first example vaxc$errno was set to %RMS-E-DNF but $status is
> %SYSTEM-F-ABORT.
>
> In the second example, a usual, aka C, getenv() doesn't set errno. Why
> setting errno to EINVAL and vaxc$errno to NOLOGNAM "is normal and as it
> should be" for the VMS implementation is not obvious to me.
You raise an interesting point, which is why our getenv() implementation sets
errno whereas apparently the standard does not specify any errno values for it.
We actively suppress the errno it sets when we've called it for our own
internal purposes, but leave it alone when called as part of satisfying a user
request. This may not be correct but it's been this way for decades so I'd
need to think long and hard about changing it.
Changing our implementation so it doesn't set errno also wouldn't really help
you because you'd still get whatever random value was in vaxc$errno. Some of
the time it would not be set and you'd get the generic failure exit, but
anything at all that sets errno could give you a surprise value that has
nothing to do with your %ENV lookup.
> Anyway, in the second example I expected a more generic return/exit code
> like %SYSTEM-F-ABORT and not an implementation specific one like
> %SYSTEM-F-NOLOGNAM.
The value you get is an accident resulting from whatever last set errno. This
is true on any operating system. Here's bash on OS X:
$ perl -e '$! = 99; $s = $ENV{X} or die qq/no such environment variable: $!\n/;'
no such environment variable: Not a STREAM
$ echo $?
99
Since a lookup in %ENV is not a syscall, the value of errno is just whatever
happens to be lying around and a call to die in these circumstances cannot
produce a predictable exit status on any operating system (as indicated in the
docs I quoted previously). In the specific case of an %ENV lookup, it's
actually more predictable on VMS than it's supposed to be.
> Whether DCL should inhibit the message or not is most probably a
> different question.
use vmsish 'hushed';
at the top of your code will inhibit the message if you wish.
>
> Anyway I'm off on vacation for the next 2 weeks, so don't expect any
> quick responses.
>
> John
>
________________________________________
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
