Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On Jul 22, 2014, at 10:18 PM, John E. Malmberg malmb...@encompasserve.org
wrote:
On 7/22/2014 7:13 AM, Craig A. Berry wrote:
On Jul 21, 2014, at 7:41 PM, John E. Malmberg wb8...@qsl.net wrote:
On 7/21/2014 7:06 PM, Craig A. Berry wrote:
DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.
Well, I wouldn't think it did, but for some reason the two are wired
together:
The idea was that if you wanted UNIX filenames, you would also want UNIX exit
statuses.
It's easy enough to ask for both, but if folks feel strongly it should stay the
way it is, I'll leave it. If we separate them, we'll have to add posix exit to
what gets turned on under bash, but that's easy to do.
I think I'm going to regard that as a bug and separate them.
The logical GNV$UNIX_SHELL is defined when bash is running. It should be
causing PERL_VMS_POSIX_EXIT to be in effect. That does not seem to be
working on encompasserve.org.
Same bug as PERL_VMS_POSIX_EXIT:
gnv_unix_shell = 0;
status = simple_trnlnm(GNV$UNIX_SHELL, val_str, sizeof(val_str));
if ($VMS_STATUS_SUCCESS(status)) {
gnv_unix_shell = 1;
If the length of the equivalence name is odd, then status will test as a
successful VMS status and it will work. But that whole problem is now fixed in
blead:
http://perl5.git.perl.org/perl.git/commitdiff/9bd30c63d934b70cf98e71983670d3e837ec38bb
I will try to get this into 5.20.1 but it will be in 5.22 in any case. Since
bash has an even number of characters in it, I don't see a reasonable
short-term workaround.
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On Jul 21, 2014, at 7:41 PM, John E. Malmberg wb8...@qsl.net wrote:
On 7/21/2014 7:06 PM, Craig A. Berry wrote:
DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.
Well, I wouldn't think it did, but for some reason the two are wired together:
s = decc$feature_get_index(DECC$FILENAME_UNIX_REPORT);
if (s = 0) {
decc_filename_unix_report = decc$feature_get_value(s, 1);
if (decc_filename_unix_report 0) {
decc_filename_unix_report = 1;
vms_posix_exit = 1;
}
else
decc_filename_unix_report = 0;
}
I think I'm going to regard that as a bug and separate them.
The perlvms documentation needs to be updated.
http://perldoc.perl.org/perlvms.html
The PERL_VMS_POSIX_EXIT needed to be 1 to get it active. ENABLE did not
work. Perl VMS documentation only mentions ENABLE
The problem is that for this feature and several others we have code that looks
like:
status = simple_trnlnm
(PERL_VMS_POSIX_EXIT, val_str, sizeof(val_str));
if ($VMS_STATUS_SUCCESS(status)) {
but simple_trnlnm does not return a VMS status. It returns zero on failure or
the length the equivalence name on success. 1 has an odd length and is
considered a success; ENABLE has an even length and is considered a failure.
That is definitely a bug, apparently one I introduced at
http://perl5.git.perl.org/perl.git/commit/8dc9d3390b257b55ff81dfb908f4621b80760d78?f=vms/vms.c.
Sorry about that. I will fix it soonish, possibly even in time for 5.20.1.
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On 7/22/2014 7:13 AM, Craig A. Berry wrote: On Jul 21, 2014, at 7:41 PM, John E. Malmberg wb8...@qsl.net wrote: On 7/21/2014 7:06 PM, Craig A. Berry wrote: DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses. Well, I wouldn't think it did, but for some reason the two are wired together: The idea was that if you wanted UNIX filenames, you would also want UNIX exit statuses. I think I'm going to regard that as a bug and separate them. The logical GNV$UNIX_SHELL is defined when bash is running. It should be causing PERL_VMS_POSIX_EXIT to be in effect. That does not seem to be working on encompasserve.org. Regards, -John
Re: Q: Can anyone explain this cursious behaviour.
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 == %X002C
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 == %X01BC
$
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
PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On Jul 20, 2014, at 3:50 PM, John E. Malmberg wb8...@qsl.net wrote: If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it is supposed to behave the way that you would normally expect. That depends on what you normally expect. PERL_VMS_POSIX_EXIT should more or less give you posixish behavior regarding exit codes. I can't think of a good reason to enable it unless you are running under bash. DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses. From a quick test on Encompasserve with PERL 5.18, that feature does not appear to be working. When that feature is working from DCL scripts or Bash you can recover the original Unix error code unless it is a VMS specific error. I do not know why the PERL_VMS_POSIX_EXIT feature does not appear to be working, I have not built/tested perl on VMS for a few years. Well it certainly does something: $ define PERL_VMS_POSIX_EXIT 1 $ perl -e $! = 66; die; Died at -e line 1. $ show symbol $status $STATUS == %X1035A212 66 is ENOTEMPTY. 66 might be embedded in that $STATUS value somewhere, transmogrified by various kinds of masking and shifting, but I'm late for dinner and have no time to debug it at the moment. Craig A. Berry mailto:craigbe...@mac.com ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On 7/21/2014 7:06 PM, Craig A. Berry wrote:
On Jul 20, 2014, at 3:50 PM, John E. Malmberg wb8...@qsl.net wrote:
If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it
is supposed to behave the way that you would normally expect.
That depends on what you normally expect. PERL_VMS_POSIX_EXIT should
more or less give you posixish behavior regarding exit codes. I can't
think of a good reason to enable it unless you are running under bash.
DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.
The perlvms documentation needs to be updated.
http://perldoc.perl.org/perlvms.html
The PERL_VMS_POSIX_EXIT needed to be 1 to get it active. ENABLE did
not work. Perl VMS documentation only mentions ENABLE
Well it certainly does something:
$ define PERL_VMS_POSIX_EXIT 1 $ perl -e $! = 66; die; Died at -e
line 1. $ show symbol $status $STATUS == %X1035A212
66 is ENOTEMPTY. 66 might be embedded in that $STATUS value
somewhere, transmogrified by various kinds of masking and shifting,
but I'm late for dinner and have no time to debug it at the moment.
$ x = %x212/8
$ show sym x
X = 66 Hex = 0042 Octal = 102
BASH-4.2$ alias perl=/perl_root/perl.exe
BASH-4.2$ perl -e \
\$s=\$ENV{X} or die \no such environment variable: '\$!'\n\
no such environment variable: 'invalid argument'
BASH-4.2$ echo $?
22
BASH-4.2$ perl -e \
\$s='nosuchdir'; chdir \$s or die \Can't cd to \$s: '\$!'\n\
Can't cd to nosuchdir: 'no such file or directory'
BASH-4.2$ echo $?
2
BASH-4.2$ uname -a
OpenVMS EISNER 0 V8.3 AlphaServer_DS20_500_MHz Alpha Alpha HP/OpenVMS
Trying the DCL examples again:
$ 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'
$ show sym $status
$STATUS == %X1035A012
$ unix = %x12/8
$ show sym unix
UNIX = 2 Hex = 0002 Octal = 002
$ 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'
$ show sym $status
$STATUS == %X1035A0B2
$ unix = %x0b2/8
$ show sym unix
UNIX = 22 Hex = 0016 Octal = 026
This feature setting also allows perl to spawn child perls and capture
the original exit codes.
Regards,
-John
RE: Q: Can anyone explain this cursious behaviour.
Hi,
first of all thanks for all the replies.
Either I don't understand or it doesn't make sense to me.
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 == %X002C 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 == %X01BC
$
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.
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.
Whether DCL should inhibit the message or not is most probably a
different question.
Anyway I'm off on vacation for the next 2 weeks, so don't expect any
quick responses.
John
Re: Q: Can anyone explain this cursious behaviour.
On 7/20/2014 2:52 PM, John Dite wrote: 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. That is the default behavior of Perl because older programs expect this behavior per documentation, all perl error exit codes were translated to 0x2c. http://perldoc.perl.org/perlvms.html If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it is supposed to behave the way that you would normally expect. From a quick test on Encompasserve with PERL 5.18, that feature does not appear to be working. When that feature is working from DCL scripts or Bash you can recover the original Unix error code unless it is a VMS specific error. I do not know why the PERL_VMS_POSIX_EXIT feature does not appear to be working, I have not built/tested perl on VMS for a few years. 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. Perl does not use getenv() for environment variables by default. It uses VMS system services to look up the current value. Anyway I'm off on vacation for the next 2 weeks, so don't expect any quick responses. Regards, -John wb8tyw@qsl.network
Q: Can anyone explain this cursious behaviour.
Hi, we came across this curious behaviour. Here enclosed please find a reproducer. When running the enclosed perl script without any logical definitions we get the message: $ perl x.pl Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5. %SYSTEM-F-NOLOGNAM, no logical name match When we define a logical name X we get: $ def/user X Y $ perl x.pl Y Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5. %SYSTEM-F-ABORT, abort $ $ perl -v This is perl 5, version 20, subversion 0 (v5.20.0) built for VMS_IA64 Kind regards John PS. Why can't a PRODUCT INSTALL of PERL leave an older installation alone (ie. do not start deleting files in the directory tree), or at least offer an OPTION to leave the old installation as is? x.pl Description: Perl program
Re: Q: Can anyone explain this cursious behaviour.
If you don't run the perl startup script, PERLLIB is undefined. That's basically the guts of PERL. The PERL.EXE tries to load it using the logical and fails. Are you running the startup you should? -- Alan 'On 7/14/2014 6:10 AM, john.d...@compinia.de wrote: Hi, we came across this curious behaviour. Here enclosed please find a reproducer. When running the enclosed perl script without any logical definitions we get the message: $ perl x.pl Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5. %SYSTEM-F-NOLOGNAM, no logical name match When we define a logical name X we get: $ def/user X Y $ perl x.pl Y Why do I get %SYSTEM-F-NOLOGNAM? at x.pl line 5. %SYSTEM-F-ABORT, abort $ $ perl -v This is perl 5, version 20, subversion 0 (v5.20.0) built for VMS_IA64 Kind regards John PS. Why can't a PRODUCT INSTALL of PERL leave an older installation alone (ie. do not start deleting files in the directory tree), or at least offer an OPTION to leave the old installation as is?
Re: Q: Can anyone explain this cursious behaviour.
Hi John, we came across this curious behaviour. Here enclosed please find a reproducer. I see the same behaviour -- and also on Perl 5.10.0, so it's not new. Looks like inappropriate propagation of the last VMS error code. PS. Why can't a PRODUCT INSTALL of PERL leave an older installation alone (ie. do not start deleting files in the directory tree), or at least offer an OPTION to leave the old installation as is? I'm not sure, but I suspect it's a required by-product of the PCSI installation process. And somewhat annoying, too! Using a PCSI kit also has problems if you want to install Perl onto a cluster-common disk, which is not the boot disk, because you end up with PRODUCT SHOW PRODUCT listing the kit on one machine but not on the other(s). The kit itself is just a complete directory tree so perhaps a PRODUCT EXTRACT command would do the trick instead? Regards, Jeremy Begg +-+ |VSM Software Services Pty. Ltd. | | http://www.vsm.com.au/ | |-| | P.O.Box 402, Walkerville, | E-Mail: jer...@vsm.com.au | | South Australia 5081 | Phone: +61 8 8221 5188 | |---| Mobile: 0414 422 947 | | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 | +-+
