Craig A. Berry wrote:
On Apr 10, 2009, at 9:55 PM, John E. Malmberg wrote:
[Dropping some names off the distribution as similar information has
been sent to them]
John E. Malmberg wrote:
Craig A. Berry wrote:
On Apr 10, 2009, at 4:20 PM, Michael G Schwern wrote:
GNV should not be assigning that logical name and later versions
than the one they've got there don't. It should be safe just to
deassign it.
$ @gnv$gnu:[lib]gnv_setup.com
$ show log bin
"BIN" = "GNV$GNU:[BIN]" (LNM$PROCESS_TABLE)
$ deassign bin
$ sh log bin
%SHOW-S-NOTRAN, no translation for logical name BIN
I was not aware of a later version than what I put on Encompasserve.
While I submitted the code to the maintainer for rebuilding the kit,
I had not heard of any new releases.
Encompasserve.org is running GNV 2.1-2 + patches that have been
submitted to HP. The GNV kit at the HP web site is still 2.1-2.
The version of GNV on Encompasserve puts the BIN logical in the
process table instead of the system table as the HP version did at
the time I installed it, so deassigning it to run Perl is the thing
to do.
I just did a quick check. With out the logical name BIN defined there
are a number of things that will not work. This is because with out
that logical name, the CRTL redirects "/bin" to be "/SYS$SYSTEM"
Eisner may have the current version of GNV installed, but it does not
appear to have the current version of the set-up command procedure.
This is Eisner:
$ search gnv$gnu:[lib]gnv_setup.com bin
$! Add GNU:[BIN] to path if it's not already there.
$ call add_path dcl$path gnv$gnu:[bin]
$ call add_path vaxc$path gnv$gnu:[bin]
$! Some hacks: Logicals needed until the binaries in GNV can be fixed.
$if f$trnlnm("BIN") .eqs. ""
$ define bin gnv$gnu:[bin]
$ bash :== $gnv$gnu:[bin]bash
Here is one of my systems with GNV v2.1-2:
$ search DISK$ALPHASYS:[SYS0.SYSCOMMON.GNV.LIB]GNV_SETUP.COM bin
$! Add GNU:[BIN] to path if it's not already there.
$ call add_path dcl$path gnu:[bin]
$ call add_path vaxc$path gnu:[bin]
$ bash :== $gnu:[bin]bash
As you can see, there is no longer a logical named bin, nor is there a
gnv$gnu logical. Nor, as I understand it, is there any reason to have
those as it's all done by mount points now. On the other hand, I'm
pretty sure you're the one who told me that, so maybe I'm missing
something.
The mount points are only visible to C programs in a UNIX format when
the DECC$POSIX_COMPLIANT_PATHNAMES option is active. This option can
not be used for most C programs because RMS does not support translating
logical names. Until that update to RMS is released either as an ECO or
a new version of VMS, effectively the POSIX_COMPLIANT_PATHNAMES modes
are not usable.
The mount point as installed by GNV 2.1-1 also are backwards of what
they should be. It can cause an infinite loop in walking directories.
The installation on Encompasserve has also corrected this issue.
The GNV$GNU is a officially registered logical name for the GNV product.
It is a violation of long standing VMS standards to have a layered
product define a logical name in the system table with out having a
registered prefix.
The installation on Encompasserve also does not define SYS$POSIX_ROOT in
the system table on GNV startup as it globally affects all programs.
Instead sys$posix_root is now defined in the process table, which is
also a hack. A patch has been submitted to HP to remove that requirement.
Removing the BIN and SYS$POSIX_ROOT logical name left behind by
GNV_SETUP.COM will require relinking all the modules, which requires
changing the link procedure.
I have not had the time to make those changes. My plan is to use the
existing GNV tools to run build the current versions of the utilities
and package them up in PCSI kits corresponding to how they are packaged
on UNIX, so eventually the GNV PCSI kit will mainly be a master kit that
installs the selected components.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
