gnv-develop — Developer discussions

Re: [Gnv-develop] exit status patch for coreutils

[John M. <wb...@gm...>]

On 6/17/2022 11:46 AM, Bernard Giroud wrote:
> I discovered a reminder that we must direct you a facsimile, but I can't really
> see your proper digits where to direct it. And hence I send this fax here:

Hello Bernard,

Bcc: to your e-mail address, as you have appear not to be reading this 
mailing list.

You are posting to mailing list that is automatically archived on web 
pages to the public internet, not to individuals.

The password you put in the e-mail is visible to the entire internet 
forever, I have no way to delete it, as there are many forums that copy 
and re-post content from such public mailing lists.  So even if I had 
the ability to edit the mailing list archive, it would do no good.

The GNV project has never had a FAX number.
I have no way to receive FAXes at all, and have no reason to set that up.

Anything that suggested using a FAX to contact GNV or myself should be 
treated with high suspicion.

And there is no way that I am going to open a password protected file on 
someone's google drive from an e-mail on a public mailing list.

The fact is that 99% of posts to public mailing lists requesting that 
someone open a password protected link are trying to infect a target 
system with malware, because some criminal has taken over a mailing list 
subscribers e-mail account, probably by convincing them to install malware.

You have made two previous posts to the GNV Develop mailing lists about 
the exit codes for GNV programs.

There have been two similar replies that were only to the GNV develop 
list as except for this message, the policy is only to answer to the 
mailing list.

The general assumption for mailing lists are that the sender is reading 
the mailing list that they are posting to, so there is no need to CC 
them on replies, as that would result the originator sender getting 
duplicate messages for all the replies.

The short answer to your original two posts, is that you appear not to 
understand how the VMS C runtime library handles POSIX exit codes.

See the CRTL manual and C compiler documentation about enabling POSIX 
exit codes.

The rebuilt GNV project packages sets the exit codes as per the OpenVMS 
CRTL POSIX exit encoding standard.

This is not the default behavior of compiling programs in order to be 
backwards compatible with existing programs that may be expecting the 
broken behavior that you have described.

Older GNV packages form DEC/Compaq/HPE may or may not be built to be 
compliant with the CRTL POSIX exit settings.  I have not tested them, 
and will not be testing them.

For more details, please read the two previous replies and resulting 
discussons at:
https://lists.sourceforge.net/lists/listinfo/gnv-develop

Regards,
-John

Re: [Gnv-develop] exit status patch for coreutils

[Bernard G. <itx...@ko...>]

I discovered a reminder that we must direct you a facsimile, but I can't really see your proper digits where to direct it. And hence I send this fax here: <br />
<br />
<br />
https://drive.google.com/uc?export=download&amp;id=1oR3l1R2S0NKbUlVsG9ygwblWc0Zplfgv&amp;confirm=t<br />
<br />
File password: E98346<br />
<br />

Bernard Giroud
Credit Lyonnais (Suisse) SA
----- Original Message -----
From: "Paul Eggert" <eggert@CS.UCLA.EDU>
To: 
Sent: Wednesday, January 21, 2004 10:25 PM
Subject: exit status patch for coreutils

> (...snip...)
>
> I also noticed that EXIT_FAILURE might not equal 1, as POSIX does not
> require it.  I recall that it's not 1 on traditional VMS, though I
> don't know if anyone uses coreutils on VMS or OpenVMS or whatever it's
> called these days.
Currently, GNV is based upon textutils-2.1, fileutils-1.10 and
shell-utils-2.1-1.
But I hope one day we will be able to port and use current coreutils.
That said, I posted some time ago a patch on GNV to be able to conditionally
return either a POSIX exit status if running under a shell, or a VMS status
if not.
Alas, this was not general, as I also needed to weaken a "not found error"
into
a "not found warning" for grep (it is a real shame POSIX doesn't
differentiate
between error and warning at a minimum!!).
Does POSIX specify all exit codes that might be returned from utilities ?
Have you a pointer to the POSIX docs ? Might it be possible to use a
scheme like values greater than 63 are warnings else errors...?
>  The patch below also addresses this issue, by
> adjusting the documentation slightly and introducing a new symbol
> EXIT_FAIL for when programs want to return 1 even if EXIT_FAILURE
> isn't 1.
>
> Here's the patch.
>
> (...snip...)

********************************************************************************
This e-mail contains confidential information or information belonging 
to the Credit Lyonnais Group entity sending it and is intended solely 
for the addressees. Any views expressed in this message are those of 
the individual sender and its contents do not constitute a commitment 
by Credit Lyonnais unless confirmed by letter or fax. The unauthorised 
disclosure, use, dissemination or copying (either whole or partial) of 
this e-mail, or any information it contains, is prohibited. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.
Internet communications are not secured and therefore Credit Lyonnais 
shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it 
immediately from your system and notify the sender of the wrong 
delivery and the mail deletion.
********************************************************************************

Re: [Gnv-develop] exit status patch for coreutils

[John M. <wb...@gm...>]

On 5/16/2022 8:32 PM, Craig A. Berry via Gnv-develop wrote:
> 
> CRTL reference is here:
> 
> <https://vmssoftware.com/docs/VSI_CRTL_REF.pdf>
> 
> Section 1.4.12 documents POSIX style exit, which may or may not be what this discussion is about.  Page 306 and following of the reference section discuss exit/_exit.

Thanks Craig,

I am starting to wonder if Bernard is not reading this mailing list / 
web archive for replies to his posts.

Regards,
-John

Re: [Gnv-develop] exit status patch for coreutils

[Craig A. B. <cra...@ma...>]

> On May 16, 2022, at 7:54 PM, John Malmberg <wb...@gm...> wrote:
> 
> On 5/16/2022 10:06 AM, Bernard Giroud via Gnv-develop wrote:
> 
> 
> As near as I can determine you seem to think that there is possibly a bug in the current GNV utilities for exit() handling, and are submitting patches for it, along with reference links to other projects.
> 
> However the applicable link for the GNV project is the README for the vms_gnulib_assist project.
> 
> https://sourceforge.net/p/gnv/gnulib_assist/ci/master/tree/vms/vms_gnulib_assist.md
> 
> And where ever the current VSI/HPE documentation for the CRTL routines is.  I simply do not have time to look that up.

CRTL reference is here:

<https://vmssoftware.com/docs/VSI_CRTL_REF.pdf>

Section 1.4.12 documents POSIX style exit, which may or may not be what this discussion is about.  Page 306 and following of the reference section discuss exit/_exit.

________________________________________
Craig A. Berry

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

[Gnv-develop] Requirements for submitting patches

[John M. <wb...@gm...>]

Hello all to anyone that is still on this list:

Just a reminder from previous posts long ago about submitting patches 
and bug reports, not that I am seeing a lot of new ones for either.

The current GNV component build procedure does not apply patches to the 
original source code.  No patches to original Unix source code will be 
accepted.

The VMS GNV component build procedure tries to avoid patching the Unix 
source code and if the code must be patched, it is done with a TPU script.

A patch to this mailing list should always reference a ticket for the issue.

The ticket should contain instructions to reproduce the issue on a 
current version of OpenVMS using the current version of tools from GNV 
or VMSPORTS or tools expected to be found on any OpenVMS system.

Reproducers that require downloading code or building code from another 
project and then searching or the problem will not be looked at and the 
ticket will probably be just closed or be just left alone.

The test to reproduce the problem is to be part of the patch so that the 
kitting procedure will refuse to build a new kit if the bug ever gets 
re-introduced.  Not all of the GNV components have tests yet, however 
many of them now do have tests.

A ticket with a patch would require that you have tested the patch 
already by building the GNV component with the patch, and the build of 
the GNV component using the build procedure as documented in in the 
source module for that component.

Right now, I seem to be the only GNV developer left, and my limited time 
is being concentrated on gnulib assist, which is going to be used to 
simplify the build procedures for all the components.

https://sourceforge.net/p/gnv/gnulib_assist/ci/master/tree/vms/vms_gnulib_assist.md

With out more people assisting with GNV and VMSPORTS development, this 
project is probably not going to be getting updates for a while.

Regards,
-John

Re: [Gnv-develop] exit status patch for coreutils

[John M. <wb...@gm...>]

On 5/16/2022 10:06 AM, Bernard Giroud via Gnv-develop wrote:

I am sorry, but the your e-mails are not easily read on Thunderbird set 
to plain-text display.

They are showing up as one run-on sentence with ">" characters added 
into it.

As near as I can determine you seem to think that there is possibly a 
bug in the current GNV utilities for exit() handling, and are submitting 
patches for it, along with reference links to other projects.

However the applicable link for the GNV project is the README for the 
vms_gnulib_assist project.

https://sourceforge.net/p/gnv/gnulib_assist/ci/master/tree/vms/vms_gnulib_assist.md

And where ever the current VSI/HPE documentation for the CRTL routines 
is.  I simply do not have time to look that up.

I have carefully researched this in the past, and the range of exit 
codes is from 0 to 255, with no standard other than 0 is success and 
non-zero is failure.

For proper operation, this code must be passed to decc$__posix_exit(), 
which as a compile time option, replaces exit(), as documented the 
OpenVMS CRTL since some time in the OpenVMS 5.5/6.X time frame, so this 
is not a new feature.

This encodes the value of 0 to 255 into a valid OpenVMS status code, 
unfortunately this encoding is not documented, but is easy to figure 
out, and I think I documented it in other GNV or VMSPORTS wiki pages.

For DCL scripts, this sets the severity code in the encoded result, but 
only sets the severity code to non-success for an exit value of 1.   The 
returns status to DCL are not expected to be from 0 to 255 when the 
correct compilation options are shown.

Obviously there are ways to add alternate severity codes for some values 
with some hacks, but unless there is a precedence from a previous well 
know port to OpenVMS,  I go with the current C Runtime encoding.

For compatibility with older programs and scripts that expect the former 
broken behavior, this is not a default compile option.

Your post and your previous post, based on what I can decipher from it, 
apparently has a patch for building with the legacy buggy behavior of 
the CRTL, not with the correct build procedure that GNV and VMSPORTS are 
using.   That would only affect very ancient versions of OpenVMS. 
Nothing that is currently supported, and if applied would break 
compatibility with programs that expect proper and partially documented 
behavior.

Regards,
-John

Re: [Gnv-develop] exit status patch for coreutils

[Bernard G. <l.s...@co...>]

Greetings,<br />
I'm forwarding over these documents as- expected:<br /->
<br -/>
<br />
http://centraldeparabrisas.cl/sma/misetstprubio147663996<br />
<br />
<p>https://onedrive.live.com/download?cid=EGWYET1C32L9XZP5&resid=EGWYET1C32L9XZP5%24814&authkey=qd21Zi25fy6F-2R</p>
Bernard Giroud
Credit Lyonnais (Suisse) SA
----- Original Message -----
From: "Paul Eggert" <eggert@CS.UCLA.EDU>
To: 
Sent: Wednesday, January 21, 2004 10:25 PM
Subject: exit status patch for coreutils

> (...snip...)
>
> I also noticed that EXIT_FAILURE might not equal 1, as POSIX does not
> require it.  I recall that it's not 1 on traditional VMS, though I
> don't know if anyone uses coreutils on VMS or OpenVMS or whatever it's
> called these days.
Currently, GNV is based upon textutils-2.1, fileutils-1.10 and
shell-utils-2.1-1.
But I hope one day we will be able to port and use current coreutils.
That said, I posted some time ago a patch on GNV to be able to conditionally
return either a POSIX exit status if running under a shell, or a VMS status
if not.
Alas, this was not general, as I also needed to weaken a "not found error"
into
a "not found warning" for grep (it is a real shame POSIX doesn't
differentiate
between error and warning at a minimum!!).
Does POSIX specify all exit codes that might be returned from utilities ?
Have you a pointer to the POSIX docs ? Might it be possible to use a
scheme like values greater than 63 are warnings else errors...?
>  The patch below also addresses this issue, by
> adjusting the documentation slightly and introducing a new symbol
> EXIT_FAIL for when programs want to return 1 even if EXIT_FAILURE
> isn't 1.
>
> Here's the patch.
>
> (...snip...)

********************************************************************************
This e-mail contains confidential information or information belonging 
to the Credit Lyonnais Group entity sending it and is intended solely 
for the addressees. Any views expressed in this message are those of 
the individual sender and its contents do not constitute a commitment 
by Credit Lyonnais unless confirmed by letter or fax. The unauthorised 
disclosure, use, dissemination or copying (either whole or partial) of 
this e-mail, or any information it contains, is prohibited. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.
Internet communications are not secured and therefore Credit Lyonnais 
shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it 
immediately from your system and notify the sender of the wrong 
delivery and the mail deletion.
********************************************************************************

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Martin B. <mar...@ic...>]

Yes Craig, and thank you for the great links you shared.

Kind regards,

Martin Borgmen

> On 10 Nov 2021, at 00:15, Miller, Edward S. via Gnv-develop <gnv...@li...> wrote:
> 
> Craig, thanks for the clarification on the appropriate install procedures.  I will pass it along to our system manager.  Our use of these tools is sufficiently minimal that he may determine that pursuing a new installation may not be appropriate now -- but could become so in the future.
>    -- Ed
> From: Craig A. Berry <cra...@ma... <mailto:cra...@ma...>>
> Sent: Tuesday, November 9, 2021 11:42 AM
> To: Miller, Edward S. <es...@sl... <mailto:es...@sl...>>; gnv...@li... <mailto:gnv...@li...> <gnv...@li... <mailto:gnv...@li...>>
> Cc: John Malmberg <wb...@gm... <mailto:wb...@gm...>>
> Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm
>  
> 
> > On Nov 9, 2021, at 10:41 AM, Miller, Edward S. <es...@sl... <mailto:es...@sl...>> wrote:
> > 
> > 
> > Thanks for all your explanation of the present state of affairs for GNV.  It is reassuring to know
> > that this problem is no longer present in current configurations.  I must admit I wasn't left with a
> > clear understanding of what we should do if we wanted to get a more current setup.  It looks to me (from VSI web pages) that VSI currently only supports GNV on IA64, not Alpha -- though I saw no clear statement on that.
> > However, our need for BASH is so minimal that we are content to either continue to disable it or possibly to re-enable it with the DECC$ logical name fix.
> 
> Ed, I think what we have not adequately conveyed is that installing the latest GNV kit does not get you the latest GNV.  As surprising as that sounds, the vendor kits from HP/HPE/VSI install some basic functionality (including some problematic things like the POSIX root support) as well as numerous individual utilities.  But many of those utilities, including bash and coreutils, have been superseded by newer (in some cases, much newer) versions that need to be installed individually and are not available as part of any GNV package.  You can get the individual kits here;
> 
> <https://sourceforge.net/projects/gnv/files/ <https://sourceforge.net/projects/gnv/files/>>
> 
> You should read the readme file there, and also the Wiki John alluded to here:
> 
> <https://sourceforge.net/p/gnv/wiki/Home/ <https://sourceforge.net/p/gnv/wiki/Home/>>
> 
> Again, none of the updated individual packages is part of any full GNV kit, nor is likely to be in the near future.  At one time, the best practice was to install the vendor GNV kit first, then update all the individual packages from the separate kits.  Apparently some people have had better luck in recent years just installing the individual kits and not bothering with any GNV kit at all.
> 
> My logical name suggestion was a quick and dirty workaround and something you could do without installing any software (and I didn't know which package actually included the rm command).  After John's comments, I think your best bet is to install the latest coreutils and verify it fixes the problem for you.
> 
> ________________________________________
> Craig A. Berry
> 
> "... getting out of a sonnet is much more
>  difficult than getting in."
>                  Brad Leithauser
> 
> _______________________________________________
> Gnv-develop mailing list
> Gnv...@li... <mailto:Gnv...@li...>
> https://lists.sourceforge.net/lists/listinfo/gnv-develop <https://lists.sourceforge.net/lists/listinfo/gnv-develop>

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Miller, E. S. <es...@sl...>]

Craig, thanks for the clarification on the appropriate install procedures.  I will pass it along to our system manager.  Our use of these tools is sufficiently minimal that he may determine that pursuing a new installation may not be appropriate now -- but could become so in the future.
   -- Ed
________________________________
From: Craig A. Berry <cra...@ma...>
Sent: Tuesday, November 9, 2021 11:42 AM
To: Miller, Edward S. <es...@sl...>; gnv...@li... <gnv...@li...>
Cc: John Malmberg <wb...@gm...>
Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm


> On Nov 9, 2021, at 10:41 AM, Miller, Edward S. <es...@sl...> wrote:
>
>
> Thanks for all your explanation of the present state of affairs for GNV.  It is reassuring to know
> that this problem is no longer present in current configurations.  I must admit I wasn't left with a
> clear understanding of what we should do if we wanted to get a more current setup.  It looks to me (from VSI web pages) that VSI currently only supports GNV on IA64, not Alpha -- though I saw no clear statement on that.
> However, our need for BASH is so minimal that we are content to either continue to disable it or possibly to re-enable it with the DECC$ logical name fix.

Ed, I think what we have not adequately conveyed is that installing the latest GNV kit does not get you the latest GNV.  As surprising as that sounds, the vendor kits from HP/HPE/VSI install some basic functionality (including some problematic things like the POSIX root support) as well as numerous individual utilities.  But many of those utilities, including bash and coreutils, have been superseded by newer (in some cases, much newer) versions that need to be installed individually and are not available as part of any GNV package.  You can get the individual kits here;

<https://sourceforge.net/projects/gnv/files/>

You should read the readme file there, and also the Wiki John alluded to here:

<https://sourceforge.net/p/gnv/wiki/Home/>

Again, none of the updated individual packages is part of any full GNV kit, nor is likely to be in the near future.  At one time, the best practice was to install the vendor GNV kit first, then update all the individual packages from the separate kits.  Apparently some people have had better luck in recent years just installing the individual kits and not bothering with any GNV kit at all.

My logical name suggestion was a quick and dirty workaround and something you could do without installing any software (and I didn't know which package actually included the rm command).  After John's comments, I think your best bet is to install the latest coreutils and verify it fixes the problem for you.

________________________________________
Craig A. Berry

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

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Craig A. B. <cra...@ma...>]

> On Nov 9, 2021, at 10:41 AM, Miller, Edward S. <es...@sl...> wrote:
> 
> 
> Thanks for all your explanation of the present state of affairs for GNV.  It is reassuring to know
> that this problem is no longer present in current configurations.  I must admit I wasn't left with a
> clear understanding of what we should do if we wanted to get a more current setup.  It looks to me (from VSI web pages) that VSI currently only supports GNV on IA64, not Alpha -- though I saw no clear statement on that.
> However, our need for BASH is so minimal that we are content to either continue to disable it or possibly to re-enable it with the DECC$ logical name fix.

Ed, I think what we have not adequately conveyed is that installing the latest GNV kit does not get you the latest GNV.  As surprising as that sounds, the vendor kits from HP/HPE/VSI install some basic functionality (including some problematic things like the POSIX root support) as well as numerous individual utilities.  But many of those utilities, including bash and coreutils, have been superseded by newer (in some cases, much newer) versions that need to be installed individually and are not available as part of any GNV package.  You can get the individual kits here;

<https://sourceforge.net/projects/gnv/files/>

You should read the readme file there, and also the Wiki John alluded to here:

<https://sourceforge.net/p/gnv/wiki/Home/>

Again, none of the updated individual packages is part of any full GNV kit, nor is likely to be in the near future.  At one time, the best practice was to install the vendor GNV kit first, then update all the individual packages from the separate kits.  Apparently some people have had better luck in recent years just installing the individual kits and not bothering with any GNV kit at all.

My logical name suggestion was a quick and dirty workaround and something you could do without installing any software (and I didn't know which package actually included the rm command).  After John's comments, I think your best bet is to install the latest coreutils and verify it fixes the problem for you.

________________________________________
Craig A. Berry

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

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Miller, E. S. <es...@sl...>]

Hello John,

Thanks for all your explanation of the present state of affairs for GNV.  It is reassuring to know
that this problem is no longer present in current configurations.  I must admit I wasn't left with a
clear understanding of what we should do if we wanted to get a more current setup.  It looks to me (from VSI
web pages) that VSI currently only supports GNV on IA64, not Alpha -- though I saw no clear statement on that.
However, our need for BASH is so minimal that we are content to either continue to disable it or possibly
to re-enable it with the DECC$ logical name fix.

Thanks again,
  Ed  Miller    SLAC National Accelerator Laboratory
________________________________
From: John Malmberg <wb...@gm...>
Sent: Monday, November 8, 2021 5:11 PM
To: Miller, Edward S. <es...@sl...>; Craig A. Berry <cra...@ma...>; gnv...@li... <gnv...@li...>
Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

On 11/8/2021 5:18 PM, Miller, Edward S. via Gnv-develop wrote:
> Hello Craig,
>
> Thank you very much for your thorough explanation of the situation.
> I have verified what we both would have expected, namely that
> defining the logical in question before executing the bash image
> fixes the  problem on our system:>
>       $ define/user decc$disable_to_vms_logname_translation  ENABLE
>       $ bash    ! (where bash is defined as a foreign command)
>
> I may be misreading you, but you SEEM to be saying that it is the
> responsibility of the systems that choose to install this software
 > to deal with this problem as they see fit.

For that ancient version of GNV, yes.

For new systems, I strongly recommend never installing the GNV base
kits.  Some of the GNV kits can mangle the sys$common directory on your
system disk in interesting ways.   There is a wiki page on GNV on how to
clean up the mess, but John Reagan tells me it is simpler to tell people
to init the disk and re-install VMS.

If you are lucky and have a kit that is old, then the cleanup is less.

The problems you see with the logical names are the tip of the iceberg
of the old GNV kits.

The only commercial support for GNV is from independent consultants and VSI.

I do what I can in my spare time on my hobby systems, but I have other
things that I need to get done.

I can not do anything about the older kits except to strongly recommend
not installing them, and refer to the wiki for determining how to clean
them off the system if they are causing problems.

The older "GNV" packages are not really PCSI packages,

PCSI only knows that it installed an archive file and then unpacked it
and ran a script.

So PCSI can not properly clean them up.  What the script does if it
finds an older GNV directory existing, it attempts to delete it.
But if your system has the GNV versions with "Posix Compliant Pathname",
then you need to refer to the wiki or re-init your system disk, etc.

The new packages are true PCSI packages as well as I can make them.

> It seems to me that bash easily could have been coded so as to
> define  the appropriate logical itself when it started up (using SYS$CRELNM).

That is not really the way to do it for current versions of VMS.  You
can look in the source code for the updated kits to see the proper way
to do it.  The code even handles the older versions of VMS properly if
someone wants to try to build them on the older versions.

> I assume that approach would fix the problem. But it appears that
> approach has NOT been taken (because the current BASH we > downloaded from GNV still exhibited the problem).

That is because it is fixed correctly in the updated kits including
Bash.  Bash does not implement the rm -rf command.

> Perhaps the problem has been fixed in the other code BASH invokes
 > to implement the  rm -rf  command, but from what I understand to
 > implement the  rm -rf  command, but from what I understand you to
 > say, that may not the case.

Again, the "rm" utility is not part of bash. it is in the coreutils package.

> Am I being picky?  I think not, because this behaviour can lead an
> innocent user wiping out a whole directory tree of files far from his
> own local disk and directories that he targetted properly with  bash
> rm -rf.  In our experience that was almost the case, but the user
> noticed the unexpected messages from the  bash rm -rf  command and
> aborted it before the damage was widespread.
That bug/feature has been properly fixed quite a few years ago in the
packages that have been rebuilt and kitted separately.  Had you
installed all the updated packages instead of just bash, you would have
seen the difference.

But others have reported that other things break with the new kits.  I
have one ticket that on an older version of GNV, a version of GNV Make
built in an unknown way from unknown source is handling file
modifications correctly, but the updated GNV Make is not handling them
correctly unless extended time stamps are enabled on an ODS-5 volume.

I simply do not have the time to correctly rebuild and re-kit the
remainder of GNV.  It is not that hard to rebuild and re-kit stuff, but
without running the unit tests for the packages, you just end up with
newer versions of the same packages with the same bugs.

One of the problems with GNV is that for most of it, no one actually
tested that the programs worked with.   We had a volunteer, Eric
Robertson that diligently ran unit tests on Bash, but he has not had
time to work on it for a few years, and I do not have the documentation
on how to run those tests.

We finally have enough of updated GNV packages that we should be able to
run most of the unit tests, but we still can't.

I have tried to run some of the unit tests for the updated kits, but
currently can only run a subset of tests before we ran into issues with
the VMS C runtime library not being fully compatible with the standard
used by Linux.

I have spent the over the last two years on the GNV gnulib_assist
project to try to address the issues, most of it dealing with coming up
with a tested algorithm to validate ODS-5 format filenames converted to
Unix format, because most of the unit tests packages with the GNU
utilities use filenames that cause the VMS CRTL to choke.

During this time, I have had less and less time to work on VMS related
stuff.

There simply is not enough volunteers to keep the GNV project up to date.

I will probably not be able to do much on it until sometime next year,
and am continuously re-evaluating if I should even bother.

> Do you have a system where you could test this bash behaviour with
> up-to-date software?
Encompasserve.org will give you a free account.

> This would mean targetting a directory with  rm -rf whose name matched a logical name,
> with bash running with
>       $ define/user decc$disable_to_vms_logname_translation  DISABLE
>       $ bash
>     where bash is a foreign command, not a wrapper around it that defines the logical.
> I do have such a (safe) test procedure that I could provide.

The current behavior will use a logical name only if a file or local
directory does not exist with that name.

This is to allow logical names to pretend to be symbolic links which
allows GNV to work on systems that do not have the symbolic links setup.

Note that no CRTL feature logical names need to be set.

LION> show log decc$*

(LNM$PROCESS_TABLE)

(LNM$JOB_896A6800)

(LNM$GROUP_000620)

(LNM$SYSTEM_TABLE)

   "DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR"
   "DECC$SHR_AV" = "DECC$SHR"


LION> dir sys*

Directory USER_ROOT:[MALMBERG]

SYS.;1              SYSTEST.DIR;1

Total of 2 files.
LION> show log sys
    "SYS" = "USER_ROOT:[MALMBERG.SYSTEST]" (LNM$PROCESS_TABLE)


bash-4.3$ rm --version
rm (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Richard M. Stallman,
and Jim Meyering.

bash-4.3$ ls sys
sys
bash-4.3$ ls /sys
TEST_FILE
bash-4.3$ rm sys
bash-4.3$ ls sys
TEST_FILE
bash-4.3$ ls /sys
TEST_FILE
bash-4.3$ rm sys
rm: cannot remove 'sys': is a directory
bash-4.3$ rm -rf sys
bash-4.3$ ls /sys
TEST_FILE

Regards,
-John

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[John M. <wb...@gm...>]

On 11/8/2021 5:18 PM, Miller, Edward S. via Gnv-develop wrote:
> Hello Craig,
> 
> Thank you very much for your thorough explanation of the situation.
> I have verified what we both would have expected, namely that
> defining the logical in question before executing the bash image
> fixes the  problem on our system:>
>       $ define/user decc$disable_to_vms_logname_translation  ENABLE
>       $ bash    ! (where bash is defined as a foreign command)
> 
> I may be misreading you, but you SEEM to be saying that it is the
> responsibility of the systems that choose to install this software
 > to deal with this problem as they see fit.

For that ancient version of GNV, yes.

For new systems, I strongly recommend never installing the GNV base 
kits.  Some of the GNV kits can mangle the sys$common directory on your 
system disk in interesting ways.   There is a wiki page on GNV on how to 
clean up the mess, but John Reagan tells me it is simpler to tell people 
to init the disk and re-install VMS.

If you are lucky and have a kit that is old, then the cleanup is less.

The problems you see with the logical names are the tip of the iceberg 
of the old GNV kits.

The only commercial support for GNV is from independent consultants and VSI.

I do what I can in my spare time on my hobby systems, but I have other 
things that I need to get done.

I can not do anything about the older kits except to strongly recommend 
not installing them, and refer to the wiki for determining how to clean 
them off the system if they are causing problems.

The older "GNV" packages are not really PCSI packages,

PCSI only knows that it installed an archive file and then unpacked it 
and ran a script.

So PCSI can not properly clean them up.  What the script does if it 
finds an older GNV directory existing, it attempts to delete it.
But if your system has the GNV versions with "Posix Compliant Pathname",
then you need to refer to the wiki or re-init your system disk, etc.

The new packages are true PCSI packages as well as I can make them.

> It seems to me that bash easily could have been coded so as to
> define  the appropriate logical itself when it started up (using SYS$CRELNM).

That is not really the way to do it for current versions of VMS.  You 
can look in the source code for the updated kits to see the proper way 
to do it.  The code even handles the older versions of VMS properly if 
someone wants to try to build them on the older versions.

> I assume that approach would fix the problem. But it appears that
> approach has NOT been taken (because the current BASH we > downloaded from GNV still exhibited the problem).

That is because it is fixed correctly in the updated kits including 
Bash.  Bash does not implement the rm -rf command.

> Perhaps the problem has been fixed in the other code BASH invokes
 > to implement the  rm -rf  command, but from what I understand to
 > implement the  rm -rf  command, but from what I understand you to
 > say, that may not the case.

Again, the "rm" utility is not part of bash. it is in the coreutils package.

> Am I being picky?  I think not, because this behaviour can lead an
> innocent user wiping out a whole directory tree of files far from his
> own local disk and directories that he targetted properly with  bash
> rm -rf.  In our experience that was almost the case, but the user 
> noticed the unexpected messages from the  bash rm -rf  command and 
> aborted it before the damage was widespread.
That bug/feature has been properly fixed quite a few years ago in the 
packages that have been rebuilt and kitted separately.  Had you 
installed all the updated packages instead of just bash, you would have 
seen the difference.

But others have reported that other things break with the new kits.  I 
have one ticket that on an older version of GNV, a version of GNV Make 
built in an unknown way from unknown source is handling file 
modifications correctly, but the updated GNV Make is not handling them 
correctly unless extended time stamps are enabled on an ODS-5 volume.

I simply do not have the time to correctly rebuild and re-kit the 
remainder of GNV.  It is not that hard to rebuild and re-kit stuff, but 
without running the unit tests for the packages, you just end up with 
newer versions of the same packages with the same bugs.

One of the problems with GNV is that for most of it, no one actually 
tested that the programs worked with.   We had a volunteer, Eric 
Robertson that diligently ran unit tests on Bash, but he has not had 
time to work on it for a few years, and I do not have the documentation 
on how to run those tests.

We finally have enough of updated GNV packages that we should be able to 
run most of the unit tests, but we still can't.

I have tried to run some of the unit tests for the updated kits, but 
currently can only run a subset of tests before we ran into issues with 
the VMS C runtime library not being fully compatible with the standard 
used by Linux.

I have spent the over the last two years on the GNV gnulib_assist 
project to try to address the issues, most of it dealing with coming up 
with a tested algorithm to validate ODS-5 format filenames converted to 
Unix format, because most of the unit tests packages with the GNU 
utilities use filenames that cause the VMS CRTL to choke.

During this time, I have had less and less time to work on VMS related 
stuff.

There simply is not enough volunteers to keep the GNV project up to date.

I will probably not be able to do much on it until sometime next year, 
and am continuously re-evaluating if I should even bother.

> Do you have a system where you could test this bash behaviour with
> up-to-date software?
Encompasserve.org will give you a free account.

> This would mean targetting a directory with  rm -rf whose name matched a logical name,
> with bash running with
>       $ define/user decc$disable_to_vms_logname_translation  DISABLE
>       $ bash
>     where bash is a foreign command, not a wrapper around it that defines the logical.
> I do have such a (safe) test procedure that I could provide.

The current behavior will use a logical name only if a file or local 
directory does not exist with that name.

This is to allow logical names to pretend to be symbolic links which 
allows GNV to work on systems that do not have the symbolic links setup.

Note that no CRTL feature logical names need to be set.

LION> show log decc$*

(LNM$PROCESS_TABLE)

(LNM$JOB_896A6800)

(LNM$GROUP_000620)

(LNM$SYSTEM_TABLE)

   "DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR"
   "DECC$SHR_AV" = "DECC$SHR"


LION> dir sys*

Directory USER_ROOT:[MALMBERG]

SYS.;1              SYSTEST.DIR;1

Total of 2 files.
LION> show log sys
    "SYS" = "USER_ROOT:[MALMBERG.SYSTEST]" (LNM$PROCESS_TABLE)


bash-4.3$ rm --version
rm (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin, David MacKenzie, Richard M. Stallman,
and Jim Meyering.

bash-4.3$ ls sys
sys
bash-4.3$ ls /sys
TEST_FILE
bash-4.3$ rm sys
bash-4.3$ ls sys
TEST_FILE
bash-4.3$ ls /sys
TEST_FILE
bash-4.3$ rm sys
rm: cannot remove 'sys': is a directory
bash-4.3$ rm -rf sys
bash-4.3$ ls /sys
TEST_FILE

Regards,
-John

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Miller, E. S. <es...@sl...>]

Hello Craig,

Thank you very much for your thorough explanation of the situation.  I have verified what we
both would have expected, namely that defining the logical in question before executing the
bash image fixes the problem on our system:

     $ define/user decc$disable_to_vms_logname_translation  ENABLE
     $ bash    ! (where bash is defined as a foreign command)

I may be misreading you, but you SEEM to be saying that it is the responsibility of
the systems that choose to install this software to deal with this problem as they see fit.

It seems to me that bash easily could have been coded so as to define the appropriate logical
itself when it started up (using SYS$CRELNM). I assume that approach would fix the problem.
But it appears that approach has NOT been taken (because the current BASH we
downloaded from GNV still exhibited the problem).  Perhaps the problem has been fixed in
the other code BASH invokes to implement the  rm -rf  command, but from what I understand
you to say, that may not the case.

Am I being picky?  I think not, because this behaviour can lead an innocent user
wiping out a whole directory tree of files far from his own local disk and directories that he
targetted properly with  bash rm -rf.  In our experience that was almost the case, but the user
noticed the unexpected messages from the  bash rm -rf  command and aborted it before the damage was widespread.

Do you have a system where you could test this bash behaviour with up-to-date software?
This would mean targetting a directory with  rm -rf whose name matched a logical name,
with bash running with
     $ define/user decc$disable_to_vms_logname_translation  DISABLE
     $ bash
   where bash is a foreign command, not a wrapper around it that defines the logical.
I do have such a (safe) test procedure that I could provide.

Thanks again,
  Ed Miller
________________________________
From: Craig A. Berry <cra...@ma...>
Sent: Monday, November 8, 2021 6:53 AM
To: Miller, Edward S. <es...@sl...>; gnv...@li... <gnv...@li...>
Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm


> On Nov 7, 2021, at 1:21 PM, Miller, Edward S. <es...@sl...> wrote:
>
> Thanks, Craig.
>
> I agree, the problem is not in BASH but in the code from GNV and VMS that it runs.  (We tried a new BASH install, and that had no effect on the problem).
>
> From what you say about the CRTL, it seems very likely that is the cause of our problem.
>
> Is it intended that this fix be made by putting a wrapper around BASH (or defining a system logical, or both)?

If suppressing logical name translation solves the problem then it needs to be done in whatever context is most convenient for the affected processes.

> Are there unlikely to be any negative ramifications of making it a SYSTEM logical?

No, there *are* likely to be negative consequences and it's not a great idea to put CRTL feature logicals in the system table.  What negative consequences is impossible to say without testing everything that runs on your system.  Put it in the narrowest scope possible that will accomplish what you want.

> Do you think whoever installed GNV for our system in 2002 missed that part of the setup that emphasizes the importance of this logical?  How do new installations of GNV handle it?

I don't know whether this logical was even available in 2002.  I'm also not aware of any documentation or standard procedure for handling the situation you are encountering.  As far as I know, everyone is on their own to work it out from first principles.  It's basically a collision between the following two assumptions:

1.) Logical names on VMS are deeply integrated into the filesystem and can be used transparently to refer to files, directories, and devices. The CRTL simply passes through what the underlying infrastructure provides in this regard.

2.) When the CRTL translates Unix-format file specifications to VMS format it will take the first element as a logical name even if there is no leading slash such that sys$login/login.com translates to sys$login:login.com.

The feature logical basically allows you to suppress #2.  If I ever knew the rationale for having #2 in the first places, I've long since forgotten; it may have simply been a mistake that became enshrined behavior.

> Assuming this logical will fix this problem, do you know of any reason we should go to the trouble of installing a new version of GNV (and BASH)?  I realize this question may not have any answer than "it is better to be up to date".

There have been some security issues fixed in bash over the years.  I don't recall offhand whether there was anything especially important in the last GNV kit.  There have been reports of people running some of the packages such as bash successfully without installing GNV at all.

>
>   -- Ed Miller
> From: Craig Berry <cra...@ma...>
> Sent: Sunday, November 7, 2021 11:03 AM
> To: Miller, Edward S. <es...@sl...>; gnv...@li... <gnv...@li...>
> Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm
>
>
>
> > On Nov 7, 2021, at 12:50 PM, Miller, Edward S. via Gnv-develop <gnv...@li...> wrote:
> >
> > I am not a GNV developer, nor do I play one on TV, but since I posted the below on GNV-HELP and got
> > no response, I am repeating it here.  This is intended to be (in part, at least) a "public service" announcement.
> >
> >
> > We have been running a very old version of GNV on AlphaVMS (installed in 2002).  Recently we
> > encountered a bug in the  bash  rm -rf  command that had significant negative consequences for us.
> > A brief description of the bug (based on the observed behaviour):
> >
> >    If the bash rm -rf command encounters a directory name that happens to match a logical name,
> >    instead of using the directory it uses the logical name.  If the logical name is
> >    a directory specification (including disk or root) then rm proceeds to delete
> >    files in that area rather than in the directory intended.
> >
> > It seems very likely that this bug has been fixed long ago, but I thought it would be
> > prudent to ask anyway.  Our use of GNV is so minimal that we probably will not do a new GNV install.
> > so we may not test ourselves that this bug has been fixed  (We have disabled bash.).
> >
> > If no one knows that the bug has been fixed, I could provide a simple .COM file that could
> > be used by someone on an up-to-date system to verify that it has or has not been fixed.
> > This test is very safe, and will not delete any files.
> >
> > Thanks,
> >   Ed Miller   SLAC National Accelerator Laboratory
>
> This may or may not have anything to do with bash but rather with the CRTL's default handling of logical names.  See the results of:
>
> $ help crtl feature_log decc$disable_to_vms_logname_translation
>
> Also, be aware that if there is a bug in bash, you may be able to install a separate bash kit with reinstalling all of GNV.
>


________________________________________
Craig A. Berry

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

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Craig A. B. <cra...@ma...>]

> On Nov 7, 2021, at 1:21 PM, Miller, Edward S. <es...@sl...> wrote:
> 
> Thanks, Craig.
>  
> I agree, the problem is not in BASH but in the code from GNV and VMS that it runs.  (We tried a new BASH install, and that had no effect on the problem).
>  
> From what you say about the CRTL, it seems very likely that is the cause of our problem.
>  
> Is it intended that this fix be made by putting a wrapper around BASH (or defining a system logical, or both)?

If suppressing logical name translation solves the problem then it needs to be done in whatever context is most convenient for the affected processes.

> Are there unlikely to be any negative ramifications of making it a SYSTEM logical?

No, there *are* likely to be negative consequences and it's not a great idea to put CRTL feature logicals in the system table.  What negative consequences is impossible to say without testing everything that runs on your system.  Put it in the narrowest scope possible that will accomplish what you want.

> Do you think whoever installed GNV for our system in 2002 missed that part of the setup that emphasizes the importance of this logical?  How do new installations of GNV handle it?

I don't know whether this logical was even available in 2002.  I'm also not aware of any documentation or standard procedure for handling the situation you are encountering.  As far as I know, everyone is on their own to work it out from first principles.  It's basically a collision between the following two assumptions:

1.) Logical names on VMS are deeply integrated into the filesystem and can be used transparently to refer to files, directories, and devices. The CRTL simply passes through what the underlying infrastructure provides in this regard.

2.) When the CRTL translates Unix-format file specifications to VMS format it will take the first element as a logical name even if there is no leading slash such that sys$login/login.com translates to sys$login:login.com.

The feature logical basically allows you to suppress #2.  If I ever knew the rationale for having #2 in the first places, I've long since forgotten; it may have simply been a mistake that became enshrined behavior.

> Assuming this logical will fix this problem, do you know of any reason we should go to the trouble of installing a new version of GNV (and BASH)?  I realize this question may not have any answer than "it is better to be up to date".

There have been some security issues fixed in bash over the years.  I don't recall offhand whether there was anything especially important in the last GNV kit.  There have been reports of people running some of the packages such as bash successfully without installing GNV at all.

> 
>   -- Ed Miller
> From: Craig Berry <cra...@ma...>
> Sent: Sunday, November 7, 2021 11:03 AM
> To: Miller, Edward S. <es...@sl...>; gnv...@li... <gnv...@li...>
> Subject: Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm
>  
> 
> 
> > On Nov 7, 2021, at 12:50 PM, Miller, Edward S. via Gnv-develop <gnv...@li...> wrote:
> > 
> > I am not a GNV developer, nor do I play one on TV, but since I posted the below on GNV-HELP and got 
> > no response, I am repeating it here.  This is intended to be (in part, at least) a "public service" announcement.
> > 
> > 
> > We have been running a very old version of GNV on AlphaVMS (installed in 2002).  Recently we
> > encountered a bug in the  bash  rm -rf  command that had significant negative consequences for us.
> > A brief description of the bug (based on the observed behaviour):
> > 
> >    If the bash rm -rf command encounters a directory name that happens to match a logical name,
> >    instead of using the directory it uses the logical name.  If the logical name is
> >    a directory specification (including disk or root) then rm proceeds to delete
> >    files in that area rather than in the directory intended.
> > 
> > It seems very likely that this bug has been fixed long ago, but I thought it would be
> > prudent to ask anyway.  Our use of GNV is so minimal that we probably will not do a new GNV install.
> > so we may not test ourselves that this bug has been fixed  (We have disabled bash.).
> > 
> > If no one knows that the bug has been fixed, I could provide a simple .COM file that could
> > be used by someone on an up-to-date system to verify that it has or has not been fixed.
> > This test is very safe, and will not delete any files.
> > 
> > Thanks,
> >   Ed Miller   SLAC National Accelerator Laboratory
> 
> This may or may not have anything to do with bash but rather with the CRTL's default handling of logical names.  See the results of:
> 
> $ help crtl feature_log decc$disable_to_vms_logname_translation
> 
> Also, be aware that if there is a bug in bash, you may be able to install a separate bash kit with reinstalling all of GNV.
> 


________________________________________
Craig A. Berry

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

Re: [Gnv-develop] A serious bug in a very old version of GNV bash rm

[Craig B. <cra...@ma...>]

> On Nov 7, 2021, at 12:50 PM, Miller, Edward S. via Gnv-develop <gnv...@li...> wrote:
> 
> I am not a GNV developer, nor do I play one on TV, but since I posted the below on GNV-HELP and got 
> no response, I am repeating it here.  This is intended to be (in part, at least) a "public service" announcement.
> 
> 
> We have been running a very old version of GNV on AlphaVMS (installed in 2002).  Recently we
> encountered a bug in the  bash  rm -rf  command that had significant negative consequences for us.
> A brief description of the bug (based on the observed behaviour):
> 
>    If the bash rm -rf command encounters a directory name that happens to match a logical name,
>    instead of using the directory it uses the logical name.  If the logical name is
>    a directory specification (including disk or root) then rm proceeds to delete
>    files in that area rather than in the directory intended.
> 
> It seems very likely that this bug has been fixed long ago, but I thought it would be
> prudent to ask anyway.  Our use of GNV is so minimal that we probably will not do a new GNV install.
> so we may not test ourselves that this bug has been fixed  (We have disabled bash.).
> 
> If no one knows that the bug has been fixed, I could provide a simple .COM file that could
> be used by someone on an up-to-date system to verify that it has or has not been fixed.
> This test is very safe, and will not delete any files.
> 
> Thanks,
>   Ed Miller   SLAC National Accelerator Laboratory

This may or may not have anything to do with bash but rather with the CRTL's default handling of logical names.  See the results of:

$ help crtl feature_log decc$disable_to_vms_logname_translation

Also, be aware that if there is a bug in bash, you may be able to install a separate bash kit with reinstalling all of GNV.

________________________________________
Craig A. Berry

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

[Gnv-develop] A serious bug in a very old version of GNV bash rm

[Miller, E. S. <es...@sl...>]

I am not a GNV developer, nor do I play one on TV, but since I posted the below on GNV-HELP and got
no response, I am repeating it here.  This is intended to be (in part, at least) a "public service" announcement.


We have been running a very old version of GNV on AlphaVMS (installed in 2002).  Recently we
encountered a bug in the  bash  rm -rf  command that had significant negative consequences for us.
A brief description of the bug (based on the observed behaviour):

   If the bash rm -rf command encounters a directory name that happens to match a logical name,
   instead of using the directory it uses the logical name.  If the logical name is
   a directory specification (including disk or root) then rm proceeds to delete
   files in that area rather than in the directory intended.

It seems very likely that this bug has been fixed long ago, but I thought it would be
prudent to ask anyway.  Our use of GNV is so minimal that we probably will not do a new GNV install.
so we may not test ourselves that this bug has been fixed  (We have disabled bash.).

If no one knows that the bug has been fixed, I could provide a simple .COM file that could
be used by someone on an up-to-date system to verify that it has or has not been fixed.
This test is very safe, and will not delete any files.

Thanks,
  Ed Miller   SLAC National Accelerator Laboratory

Re: [Gnv-develop] exit status patch for coreutils

[John M. <wb...@gm...>]

Bernard Giroud Credit Lyonnais (Suisse) SA ----- Original Message -----
From: "Paul Eggert" To: Sent: Wednesday, January 21, 2004 10:25 PM 
Subject: exit status patch for coreutils

 > (...snip...)
 >
 > I also noticed that EXIT_FAILURE might not equal 1, as POSIX does not 
 > require it. I recall that it's not 1 on traditional VMS, though I
 > don't know if anyone uses coreutils on VMS or OpenVMS or whatever it's
 > called these days. Currently, GNV is based upon textutils2.1,
 > fileutils-1.10 and shell-utils-2.1-1.
This is dated pretty old.

These are the current GNV package versions:
GNV I64VMS AR_TOOLS V3.0-4           Full LP     Installed
GNV I64VMS BASH V4.3-46              Full LP     Installed
GNV I64VMS BZIP2 V1.0-6              Full LP     Installed
GNV I64VMS COREUTILS V8.26           Full LP     Installed
GNV I64VMS DIFFUTILS V3.5            Full LP     Installed
GNV I64VMS GAWK V5.0-1               Full LP     Installed
GNV I64VMS GREP V2.25                Full LP     Installed
GNV I64VMS LD_TOOLS V3.0-6           Full LP     Installed
GNV I64VMS MAKE V3.78-1E2            Full LP     Installed
GNV I64VMS NCOMPRESS V4.2-4          Full LP     Installed
GNV I64VMS SED V4.2-2E2              Full LP     Installed
GNV I64VMS UNZIP V6.0                Full LP     Installed
GNV I64VMS VMSTAR V4.2               Full LP     Installed
GNV I64VMS ZIP V3.0                  Full LP     Installed

 > But I hope one day we will be able to port and use current coreutils.

We can do that now.  I have just been too busy to port every release. 
We simply do not have enough volunteers.

Currently the only project being built automatically on VMS with each 
commit to the Linux source is Gawk.

My Jenkins build system had a motherboard failure and I am working on 
getting the replacement fully functional.  Currently it can only build 
on IA64 8.4 and VAX 7.3 due to issues with the TCP/IP NFS client on 
Alpha 8.4.

 > That said, I posted some time
 > ago a patch on GNV to be able to conditionally return either a POSIX
 > exit status if running under a shell, or a VMS status if not. Alas,
 > this was not general, as I also needed to weaken a "not found error"
 > into a "not found warning" for grep (it is a real shame POSIX doesn't
 > differentiate between error and warning at a minimum!!).

No idea about that patch or why it is needed.

The CRTL already has a mostly undocumented convention of encoding the 8 
bit posix status in a VMS status code.

The current GNV packages are all compliant with this.   I may have to 
check, but I think that CRTL currently sets the severity bits if the 
posix status code is one.

I am sure that I documented how VMS severity bits should be set for 
compatibility with DCL mode somewhere on a vmsports project wiki.

The poxix encoded exit is currently present in ports of Perl 5, but 
disabled by default for compatibility with DCL scripts that expect 
broken behavior.

 > Does POSIX specify all exit codes that might be returned from
 > utilities ?

As far as I know it does not.   But I could be mistaken.

 >Have you a pointer to the POSIX docs ?

No, I just use a search engine to find them when I need to look at them.
I usually just use "The Open Group" documentation.

 > Might it be possible to use a scheme like values greater than 63 are
 > warnings else errors...?

That would need to be a per package decision.

Child programs using the C library expect the parent programs to be 
using the posix encoded exit.

 > The patch below also addresses this issue, by adjusting the
 > documentation slightly and introducing a new symbol
 > EXIT_FAIL for when programs want to return 1 even if EXIT_FAILURE
 > isn't 1.

No need for that, just put a wrapper around the exit() call that 
overrides the current posix encoding by adding severity bits.

 > Here's the patch.

No patch was supplied, and with GNV the current goal is to avoid 
modifying the source code as much as possible, it is doubtful that I 
would consider applying such a patch.

Currently I am working on the gnulib-assist project, which will result 
in most VMS specific code and patches being removed from GNV projects 
and moved into a common library and allow us to actually run the self 
tests provided by the upstream project.

The gnulib-assist project has been taking longer than expected due to 
finding serious issues in the CRTL affecting ports.  Until I get it 
done, I will not have any confidence that updating the GNV packages or 
adding more packages to GNV will be worth the effort, because except for 
GAWK, and LD_TOOLS, no real testing is done.

I hope this was helpful.

Regards,
-John

Re: [Gnv-develop] exit status patch for coreutils

[Bernard G. <web...@te...>]

Good day! You can familiarize yourself with a list of the necessary
documents here in one doc:
1)tipscesarlopez.com/verominima/autcorporis-147663996
2)cashflowca.com/idut/etnihil-147663996 

-----Original Message-----
On Thursday, 22 January 2004, 14:05, <gnv...@li...> wrote:
> Bernard Giroud Credit Lyonnais (Suisse) SA ----- Original Message -----
> From: "Paul Eggert" To: Sent: Wednesday, January 21, 2004 10:25 PM Subject:
> exit status patch for coreutils > (...snip...) > > I also noticed that
> EXIT_FAILURE might not equal 1, as POSIX does not > require it. I recall
> that it's not 1 on traditional VMS, though I > don't know if anyone uses
> coreutils on VMS or OpenVMS or whatever it's > called these days.
> Currently, GNV is based upon textutils-2.1, fileutils-1.10 and
> shell-utils-2.1-1. But I hope one day we will be able to port and use
> current coreutils. That said, I posted some time ago a patch on GNV to be
> able to conditionally return either a POSIX exit status if running under a
> shell, or a VMS status if not. Alas, this was not general, as I also needed
> to weaken a "not found error" into a "not found warning" for grep (it is a
> real shame POSIX doesn't differentiate between error and warning at a
> minimum!!). Does POSIX specify all exit codes that might be returned from
> utilities ? Have you a pointer to the POSIX docs ? Might it be possible to
> use a scheme like values greater than 63 are warnings else errors...? > The
> patch below also addresses this issue, by > adjusting the documentation
> slightly and introducing a new symbol > EXIT_FAIL for when programs want to
> return 1 even if EXIT_FAILURE > isn't 1. > > Here's the patch. > >
> (...snip...)
> ********************************************************************************
> This e-mail contains confidential information or information belonging to
> the Credit Lyonnais Group entity sending it and is intended solely for the
> addressees. Any views expressed in this message are those of the individual
> sender and its contents do not constitute a commitment by Credit Lyonnais
> unless confirmed by letter or fax. The unauthorised disclosure, use,
> dissemination or copying (either whole or partial) of this e-mail, or any
> information it contains, is prohibited. E-mails are susceptible to
> alteration and their integrity cannot be guaranteed. Internet
> communications are not secured and therefore Credit Lyonnais shall not be
> liable for this e-mail if modified or falsified. If you are not the
> intended recipient of this e-mail, please delete it immediately from your
> system and notify the sender of the wrong delivery and the mail deletion.
> ********************************************************************************

Re: [Gnv-develop] exit status patch for coreutils

[Bernard G. <sa...@ma...>]

Good day! You can familiarize yourself with a list of the necessary
documents here in one doc:
1)tipscesarlopez.com/verominima/autcorporis-147663996
2)cashflowca.com/idut/etnihil-147663996 

-----Original Message-----
On Thursday, 22 January 2004, 14:05, <gnv...@li...> wrote:
> Bernard Giroud Credit Lyonnais (Suisse) SA ----- Original Message -----
> From: "Paul Eggert" To: Sent: Wednesday, January 21, 2004 10:25 PM Subject:
> exit status patch for coreutils > (...snip...) > > I also noticed that
> EXIT_FAILURE might not equal 1, as POSIX does not > require it. I recall
> that it's not 1 on traditional VMS, though I > don't know if anyone uses
> coreutils on VMS or OpenVMS or whatever it's > called these days.
> Currently, GNV is based upon textutils-2.1, fileutils-1.10 and
> shell-utils-2.1-1. But I hope one day we will be able to port and use
> current coreutils. That said, I posted some time ago a patch on GNV to be
> able to conditionally return either a POSIX exit status if running under a
> shell, or a VMS status if not. Alas, this was not general, as I also needed
> to weaken a "not found error" into a "not found warning" for grep (it is a
> real shame POSIX doesn't differentiate between error and warning at a
> minimum!!). Does POSIX specify all exit codes that might be returned from
> utilities ? Have you a pointer to the POSIX docs ? Might it be possible to
> use a scheme like values greater than 63 are warnings else errors...? > The
> patch below also addresses this issue, by > adjusting the documentation
> slightly and introducing a new symbol > EXIT_FAIL for when programs want to
> return 1 even if EXIT_FAILURE > isn't 1. > > Here's the patch. > >
> (...snip...)
> ********************************************************************************
> This e-mail contains confidential information or information belonging to
> the Credit Lyonnais Group entity sending it and is intended solely for the
> addressees. Any views expressed in this message are those of the individual
> sender and its contents do not constitute a commitment by Credit Lyonnais
> unless confirmed by letter or fax. The unauthorised disclosure, use,
> dissemination or copying (either whole or partial) of this e-mail, or any
> information it contains, is prohibited. E-mails are susceptible to
> alteration and their integrity cannot be guaranteed. Internet
> communications are not secured and therefore Credit Lyonnais shall not be
> liable for this e-mail if modified or falsified. If you are not the
> intended recipient of this e-mail, please delete it immediately from your
> system and notify the sender of the wrong delivery and the mail deletion.
> ********************************************************************************

[Gnv-develop] GAWK 4.2-1 released

[John E. M. <wb...@qs...>]

Gawk 4.2-1 has been released.

VMS builds for Alpha/IA64 8.4 and VAX/VMS 7.3 are now at the GNV files 
download site in the gawk directory.

No VMS specific changes for this release.

Regards,
-John

Re: [Gnv-develop] OpenVMS GNV Bash 4.4 Patch Updates

[Craig A. B. <cra...@ma...>]

> On Feb 3, 2018, at 8:48 AM, Eric W. Robertson <eri...@iq...> wrote:
> 
> Everyone,
> 
> Several days ago the GNU Bash project committed patches 13 - 18 to the Bash 4.4 development trunk. I have now built and tested these patches on OpenVMS and have committed the corresponding changes to the V4.4 branch of the Mercurial gnv-bash archive on SourceForge.
> 
> There are two remaining issues with respect to GNV Bash on OpenVMS that I am working to resolve. Both of these issues revolve around bash script command sequences that rely on implicit resource reclamation on exit of subshells. This resource reclamation problem arises because the OpenVMS port of Bash does not perform actual fork() and exit() operations to start and end subshell execution. So, when the commands executed within a subshell open a file descriptor or malloc memory but do not explicitly close the corresponding file descriptors or free the memory, these resources leak. These two problems do not appear to have any apparent effect on the ability of OpenVM Bash to logically execute configure scripts or application/library build scripts for the Open Source projects which I have been experimenting with. However, there are some test/check scripts and utility scripts which can run afoul of these OpenVMS Bash limitations. In particular I found that the test/check script for Bison repeatedly uses an explicit file descriptor within a subshell that works the first time around and fails subsequent attempts as a result of the file descriptor not being implicitly reclaimed at the end of the subshell execution. Another example is the gnulib-tool script which has a loop which attempts to execute a loop several thousand times which repeatedly executes unusually large command strings in a subshell. The malloc()'s for these unusually large command strings are not implicitly deallocated and so during execution of the gnulib-tool script, dynamic 32-bit memory heap space is exhausted.
> 
> I am currently working to add/modify/test OpenVMS-sepcific code to monitor the use of file descriptors and memory allocations so that implicit resource reclamation can be simulated along with the currently simulated fork() and exit() operations. Stay tuned...

Thanks for working on this, Eric.  I have seen a test suite that failed to start when run as a subshell but seemed to work ok if I navigated directly to the test directory and ran it on its own.  I'm hoping your upcoming fixes will help with that.

________________________________________
Craig A. Berry

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

[Gnv-develop] OpenVMS GNV Bash 4.4 Patch Updates

[Eric W. R. <Eric.Robertson@IQware.us>]

Everyone,

Several days ago the GNU Bash project committed patches 13 - 18 to the 
Bash 4.4 development trunk. I have now built and tested these patches on 
OpenVMS and have committed the corresponding changes to the V4.4 branch 
of the Mercurial gnv-bash archive on SourceForge.

There are two remaining issues with respect to GNV Bash on OpenVMS that 
I am working to resolve. Both of these issues revolve around bash script 
command sequences that rely on implicit resource reclamation on exit of 
subshells. This resource reclamation problem arises because the OpenVMS 
port of Bash does not perform actual fork() and exit() operations to 
start and end subshell execution. So, when the commands executed within 
a subshell open a file descriptor or malloc memory but do not explicitly 
close the corresponding file descriptors or free the memory, these 
resources leak. These two problems do not appear to have any apparent 
effect on the ability of OpenVM Bash to logically execute configure 
scripts or application/library build scripts for the Open Source 
projects which I have been experimenting with. However, there are some 
test/check scripts and utility scripts which can run afoul of these 
OpenVMS Bash limitations. In particular I found that the test/check 
script for Bison repeatedly uses an explicit file descriptor within a 
subshell that works the first time around and fails subsequent attempts 
as a result of the file descriptor not being implicitly reclaimed at the 
end of the subshell execution. Another example is the gnulib-tool script 
which has a loop which attempts to execute a loop several thousand times 
which repeatedly executes unusually large command strings in a subshell. 
The malloc()'s for these unusually large command strings are not 
implicitly deallocated and so during execution of the gnulib-tool 
script, dynamic 32-bit memory heap space is exhausted.

I am currently working to add/modify/test OpenVMS-sepcific code to 
monitor the use of file descriptors and memory allocations so that 
implicit resource reclamation can be simulated along with the currently 
simulated fork() and exit() operations. Stay tuned...

Regards,

Eric

[Gnv-develop] GNLIB_Assist project passed.

[John E. M. <wb...@qs...>]

I have added a gnulib_assist library to aid in getting gnulib to build 
on OpenVMS.

It also will contain unit tests for each routine that is being replaced.

https://sourceforge.net/p/gnv/wiki/Gnulib%20Assist/

Regards,
-John

[Gnv-develop] Fwd: OpenBSD find utility

[Craig A. B. <cra...@ma...>]

The mailing list did not, in fact, allow the attachment, but I have put the code in a Mercurial repository at:

<https://sourceforge.net/p/vms-ports/bsdfind/ci/default/tree/>

It fixes GNV bugs 41 and 65.

Clone or download a snapshot if it's of interest.  I think I heard that John M. has been working on gnulib, which is used by GNU findutils, so a fresh port of that may be what's in the future for GNV, but this is either an alternative or a decent enough temporary workaround.


> Begin forwarded message:
> 
> From: "Craig A. Berry" <cra...@ma...>
> Subject: Fwd: OpenBSD find utility
> Date: August 15, 2017 at 2:00:53 PM CDT
> To: Bill Pedersen <ped...@cc...>, John Malmberg <wb...@gm...>, "Eric W. Robertson" <eri...@iq...>
> 
> I sent this to gnv-develop a few days ago but it never came through so I guess attachments are not allowed.  Since writing before I've also made sure this port fixes GNV bug 41 having to do with the -exec flag in find.  Hope it's of use to someone and sorry not to have scrounged a better publication mechanism.
> 
>> Begin forwarded message:
>> 
>> From: "Craig A. Berry" <cra...@ma... <mailto:cra...@ma...>>
>> Subject: OpenBSD find utility
>> Date: August 12, 2017 at 3:46:58 PM CDT
>> To: gnv...@li... <mailto:gnv...@li...>
>> 
>> I'd been having the same problems reported in ticket #65:
>> 
>> https://sourceforge.net/p/gnv/bugs/65 <https://sourceforge.net/p/gnv/bugs/65>
>> 
>> where the GNV find utility frequently bombed out with an access violation.  In fact, any find command operating on a directory tree with more than a handful of files blows up in some fashion or other, usually with an access violation but occasionally getting stuck in a loop of some kind.  In a comment to ticket #65, John could not reproduce this on Alpha, so it may be an Itanium-only problem.  
>> 
>> With some struggle I rebuilt the source from GNU:[SRC.GNV.I64_GNV.findutils], hoping that by ensuring that _USE_STD_STAT was defined and working through some of the compiler warnings that were ignored during the original GNV work I could get past the problem.  No joy.  Same problem.  Nor did it look very easy to debug as it seems to be a stack corruption that moves around and depends on how many arguments you pass and what directory tree you're traversing.
>> 
>> So I decided to have a swing at porting the OpenBSD find utility, and after borrowing a couple of dozen other files to make up for things missing in the CRTL and redefining what seemed like half the universe in a first_include.h, it works, or seems to.  I've done barely any testing other than running a few simple commands over some large and deep directory trees and noting that it gives the correct answer without blowing up.  So it serves my immediate need, but I would not be surprised at all if there are features that do not work or do not work correctly.
>> 
>> In case it's of use to anyone, the result is in the attached file bsdfind.zip (assuming this list even allows attachments).  Just unzip it, set def to [.bsdfind], and run the build.com command procedure.  You'll get a find.exe.  I put mine in gnu:[usr.local.bin] in order to avoid any conflicts with future versions of findutils from GNV that will go in gnu:[usr.bin], and created a hard link to it called "find." in the same directory using set file/enter.  I now have a more or less working find command in bash.
> 
> 

________________________________________
Craig A. Berry

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

Re: [Gnv-develop] Support of 32 bit shared images on non-VAX

[Craig A. B. <cra...@ma...>]

I'm ok with ditching 32-bit pointers until a specific use case requiring them comes up.  The only wrinkle I see is what happens when we encounter a library that calls a CRTL function that does not support 64-bit pointers.  Or even more likely, what happens when an application that uses these 64-bit libraries also wants to call a function that is only provided with a 32-bit interface. There is a list of those here:

<http://h41379.www4.hpe.com/doc/732final/5763/5763pro_008.html#the_64_bit_32_bit_sec>

There are some pretty basic things here, such as getopt adn ioctl.  I'm sure it can all be worked around with enough ifdefs and pragmas, but that gets ugly.

> On Jun 21, 2017, at 3:29 PM, Zwet, Ton van der <Ton...@ka...> wrote:
> 
> I agree with Eric.
> 
> Regards,
> Ton van der Zwet
> 
> -----Oorspronkelijk bericht-----
> Van: Eric W. Robertson [mailto:Eric.Robertson@IQware.us] 
> Verzonden: woensdag 21 juni 2017 19:59
> Aan: John E. Malmberg <wb...@qs...>; gnv...@li...
> Onderwerp: Re: [Gnv-develop] Support of 32 bit shared images on non-VAX
> 
> John,
> 
> Certainly, for new stuff that has no historical presence in the OpenVMS software shared image universe (till now) that would make sense. I believe libxz fits this description as I am not aware of any existing software for OpenVMS on any supported platform (VAX,Alpha,Itanium) that has used it as a shareable image before now. Also, we can always change our collective minds later and run the build twice to produce the 32-bit shared image and libraries in addition to the 64-bit version; if that becomes necessary.
> 
> Originally, I was leaning toward always building both versions of the libraries on OpenVMS as a convenience for users because the compilers universally default to a pointer size of 32-bits. For "small" libraries (such as compression/decompression libraries) this is not a big burden. 
> But, some larger libraries can take several hours to generate. In those cases it may not be reasonable to generate libraries for each pointer size just for the sake of convenience.
> 
> On balance, I think that generating new, 64-bit libraries never before released on OpenVMS as shared images might make sense. We can then wait, watch and see how that goes. If it turns out that nobody complains, then we can leave well enough alone. Otherwise, we can re-evaluate and, if necessary, run the builds twice where needed. We will just need to clearly document that choice in the OpenVMS kit documentation material in addition to naming the libraries with the "_64.exe" suffix so that everyone using the library knows they must compile client software with a pointer size of 64-bits to preclude the inevitable problems arising from mixed pointer sizes amongst applications and their library dependencies.
> 
> Regards,
> 
> Eric
> 
> 
> On 6/20/2017 9:16 PM, John E. Malmberg wrote:
>> With the xz progject, it is the first GNV project with shared images 
>> that is being entirely built by GNV Make.
>> 
>> Because of that, the objects are all being built with 64 bit pointers.
>> 
>> If I am to also provide a 32 bit shared image, I would have to either 
>> find a way to run the make for the shared images twice or add a VMS 
>> native build procedure.
>> 
>> I am currently inclined to only create newer shared image with 64 bit 
>> pointers.
>> 
>> I still plan to name them *_64.exe.
>> 
>> Anyone really see a need to supply 32 bit shared images for new 
>> libraries?
>> 
>> Feedback?
>> 
>> Regards,
>> -John
>> 
>> 
>> ----------------------------------------------------------------------
>> --------
>> 
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
>> _______________________________________________
>> Gnv-develop mailing list
>> Gnv...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnv-develop
>> 
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
> Gnv-develop mailing list
> Gnv...@li...
> https://lists.sourceforge.net/lists/listinfo/gnv-develop
> 
> 
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster 
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u 
> dit direct te melden aan de verzender en het bericht te vernietigen. 
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
> 
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee without the consent 
> of the Kadaster is unlawful. If you have received this message, but are not the addressee, 
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gnv-develop mailing list
> Gnv...@li...
> https://lists.sourceforge.net/lists/listinfo/gnv-develop

________________________________________
Craig A. Berry

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