Re: Q: Can anyone explain this cursious behaviour.

[Alan Winston]

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...@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?
>
>

[Jeremy Begg]

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 |
+---------------------------------------------------------+

[john...@compinia.de]

Jeremy,

On 15.07.2014 03:24, Jeremy Begg wrote:
> 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.
>

I have just joined this distribution list, so what do you reckon are the
chances that this can be and will be resolved in the near
future?Obviously for a customer script we have to suppress this
misleading output, by other means.

>> 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?
>

Of course that is one approach, but seeing that someone has gone to all
the trouble of 'packetizing' perl it is a shame.
Surely in the 'open source' space one is never sure whether one's open
source based application is going to work with a new version of, in this
case perl, especially if one has compiled additional modules. So it
would make sense, to let you switch environments, from old to new and
back again. The way the PCSI works for perl at the moment, has become a
nugatory activity.


Kind regards
John

[Willem Grooters]

On Tue, 15 Jul 2014 09:57:42 +0200 "john...@compinia.de" <john...@compinia.de> wrote:

>> 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?
>>
>Of course that is one approach, but seeing that someone has gone to all
>the trouble of 'packetizing' perl it is a shame.
>Surely in the 'open source' space one is never sure whether one's open
>source based application is going to work with a new version of, in this
>case perl, especially if one has compiled additional modules. So it
>would make sense, to let you switch environments, from old to new and
>back again. The way the PCSI works for perl at the moment, has become a
>nugatory activity.
>
>Kind regards
>John
>

ANY new environment should (imho) support code and programs develloped in an older environment. It's called backward compatbility
(IIRC) and this is indeed a concept that is missing in many 'modern' environments - mainly *X based, and not necessarily
open-source (remember older versions of java?) or non-VMS (rememner SWS (AKA Apache?)).
In some projects, there now is a fairly good awareness of the need, in many projects, though not always possible (OpenSSL 1.0 s.
0.9.8)....

It is also common to install software of a predefined location - especially in the Linux world. The name _may_ include a version
indication, in which case you will need ta adapt your references, eventually rebuild your software alltogether.
Worst case however, it will be the same location as the previous version - like PCSI. Or even - as I have encountered - there is no
choice than to use this 'default' location.
Using open-source that installes this way, I have run into severe trouble bacause the new version was not usable at all (it
actually ruined the database).

The remedy is simple: Install default, rename the rootdirectory to include the version and adapt all code that refers to the
environment to match this new name. Switching between versions is now easy by defining a one of just a few logicals.

But the best solution is - as always - to PREVENT this from happening. PCSI is fine for software that is REALLY backward
compatible, or is at the base of the system. Otherwise, use other methods; for example delivering object files and all procedures
and files needed to link them together locally - LINK is included in teh OpenVMS system. (the WASD webserver is distributed that
way).

Willem

[Craig A. Berry]

On Jul 15, 2014, at 2:57 AM, john...@compinia.de wrote:

> On 15.07.2014 03:24, Jeremy Begg wrote:
>> 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.
>>
> I have just joined this distribution list, so what do you reckon are the chances that this can be and will be resolved in the near future?Obviously for a customer script we have to suppress this misleading output, by other means.

I don't think there is a way to fix it. What's happening is the combination of two automatic behaviors:

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 behavior.

The following is from the documentation for the die function and describes how exit codes work on Unix:

========
as $! is the value of C's "errno", which can be set by
any system call, this means that the value of the exit code used
by "die" can be non-predictable, so should not be relied upon,
other than to be non-zero.
========

The main difference on VMS is that you get (by default) a native 32-bit condition value rather than just a non-zero number, and die ends up using SS$_ABORT by default if vaxc$errno is not set. So what you're seeing is really the documented behavior of die.

Another way of looking at this is that your program dies without having encountered an error, so it picks up whatever previous error happens to be lying around. Just as in C errno is only valid immediately after a failed system call, the VMS exit code retrieved by die is also only valid immediately after a failed system call.

One way to solve your problem is to just clear errno ($! in Perl) and vaxc$errno ($^E in Perl) before calling die:

=======
print $ENV{X}, "\n";

# Clear these so die isn't confused.
$! = 0;
$^E = 0;

my $whatever = shift @ARGV or die "missing argument";
exit 0;
=======

However, it seems to me clearer to code exactly what you want rather than rely on the behavior of die, which really isn't what you want:

=======
use constant SS_INSFARG => 276;

print $ENV{X}, "\n";

my $whatever = shift @ARGV;
exit SS_INSFARG unless $whatever;

exit 0;
=======


________________________________________
Craig A. Berry
mailto:craig...@mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser

[Craig A. Berry]

On Jul 15, 2014, at 2:57 AM, john...@compinia.de wrote:

I was dismayed when I prepared the 5.20 kits to discover that it removed the 5.18 installation. I looked long and hard in the docs for a way to make that optional and never found anything. If someone knows of a way to do that with PCSI, please fill me in.

Since the default install location has the version number in it, there is absolutely no reason a 5.18 installation and a 5.20 installation cannot happily coexist. One thing I haven't tried is re-installing 5.18 after installing 5.20. If someone wants to try that, please let us know how it goes.

The difficulty here is that, for example, 5.18.2 really should remove 5.18.1 before installing because (by default) they go in the same directory, but 5.20.0 should not remove 5.18.x. The only way I can see to do that with PCSI is to include the version number in the product name, so the product name, instead of "PERL," would be "PERL518," "PERL520," etc. This is what HP has done with Java, where you have "JAVA150" and "JAVA60." I guess the earliest that could happen now would be for 5.22 next March.

Of course there is no requirement to use the PCSI kits. People can build from source and install wherever they like.

[Jeremy Begg]

Hi Craig,

Thanks for the clarification around the behaviour of "die" and how to avoid
it.

>> Of course that is one approach, but seeing that someone has gone to all
>> the trouble of 'packetizing' perl it is a shame.
>>
>> Surely in the 'open source' space one is never sure whether one's open
>> source based application is going to work with a new version of, in this
>> case perl, especially if one has compiled additional modules. So it would
>> make sense, to let you switch environments, from old to new and back again.
>> The way the PCSI works for perl at the moment, has become a nugatory
>> activity.

>I was dismayed when I prepared the 5.20 kits to discover that it removed
>the 5.18 installation. I looked long and hard in the docs for a way to make
>that optional and never found anything. If someone knows of a way to do
>that with PCSI, please fill me in.

PCSI is great for installing stuff into VMS$COMMON. As soon as you stray
from that it gets trickier.

>The difficulty here is that, for example, 5.18.2 really should remove
>5.18.1 before installing because (by default) they go in the same directory,
>but 5.20.0 should not remove 5.18.x. The only way I can see to do that with
>PCSI is to include the version number in the product name, so the product
>name, instead of "PERL," would be "PERL518," "PERL520," etc. This is what
>HP has done with Java, where you have "JAVA150" and "JAVA60." I guess the
>earliest that could happen now would be for 5.22 next March.

I would be happy with that.

>Of course there is no requirement to use the PCSI kits. People can build
>from source and install wherever they like.

Your release announcement should include a pointer to the source files (even
if it's the vanilla CPAN site).

Thanks for your good work!

Jeremy Begg

[John Dite]

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 == "%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"
$
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

[John E. Malmberg]

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
wb8...@qsl.network

[Craig A. Berry]

On Jul 20, 2014, at 2:52 PM, John Dite <john...@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.

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]

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.

[John E. Malmberg]

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 = 00000042 Octal = 00000000102

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 = 00000002 Octal = 00000000002

$ 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 = 00000016 Octal = 00000000026

This feature setting also allows perl to spawn child perls and capture
the original exit codes.

Regards,
-John

[Craig A. Berry]

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.

[John E. Malmberg]

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

[Craig A. Berry]

On Jul 22, 2014, at 10:18 PM, John E. Malmberg <malm...@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.