|
|
|
|
|
|
| Author |
Message |
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
 Posted: Wed Feb 01, 2006 2:37 am Post subject:
Re: patch@26996 - patch around stat("_NLA0:") bug
|
|
|
Mark Berryman wrote:
| Quote: |
I am curious. Why would you not want to simply define _USE_STD_STAT?
|
Perl currently is coded to expect only the behavior of the traditional
but non standard compliant stat structure and related calls and then
give an illusion that the stat structure is compliant.
Most of the infrastructure is in place for the enabling it, but I want
to get all the long filename support in first.
What is needed is that the stat/fstat calls will need to cache the short
path and filename being tested in space that is now reserved in the
mystat structure. The perl_cando code will then reference this instead
of a static cache that is used now for both stat and fstat().
At that point, I do not think that the static cache will be needed, and
also after that change, there should be no reason for VMS.C to track the
differences between the two stat structures.
| Quote: | Is it because this feature is not available on the VAX?
|
No, but it is not available before OpenVMS 8.2 and requires 64 bit
support by the compiler.
| Quote: | How old of a VMS version does this version of Perl need to compile on?
|
I am not sure. I think I have seen some VMS 7.2-x build results recently.
DEC/COMPAQ/HP C that is capable of building Perl is available back to
5.5-2, but it would take me a bit to set up a system that old.
Now as to why to add support for the standard compliant stat structure
is that the dev_t information can be interchanged between applications
to identify when multiple filenames resolve to the same file.
There may be other cases where having the correct dev_t value could be
significant.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
 |
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Wed Feb 01, 2006 3:33 pm Post subject:
Re: patch@26996 - patch around stat("_NLA0:") bug
|
|
|
On Tuesday, January 31, 2006, at 04:54PM, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> wrote:
| Quote: |
I am curious. Why would you not want to simply define _USE_STD_STAT?
Is it because this feature is not available on the VAX? How old of a
VMS version does this version of Perl need to compile on?
|
I don't know offhand whether it's available on VAX or what the minimum VMS version is, and I'd prefer not to break things without at least knowing what will break. From John's post it sounds like it won't do us any good until v8.2 or later, so I can't see any reason to try enabling it before that.
I've successfully built bleadperl recently on OpenVMS Alpha v7.2-1, with v6.4 of the C compiler. Most likely some of the recent changes have broken pre-v7.0 builds, but I don't have access to anything that old to test with. |
|
| Back to top |
|
|
Mark Berryman
*nix forums addict
Joined: 04 Aug 2005
Posts: 50
|
| Posted: Wed Feb 01, 2006 4:02 pm Post subject:
Re: patch@26996 - patch around stat("_NLA0:") bug
|
|
|
John E. Malmberg wrote:
| Quote: | Mark Berryman wrote:
I am curious. Why would you not want to simply define _USE_STD_STAT?
Perl currently is coded to expect only the behavior of the traditional
but non standard compliant stat structure and related calls and then
give an illusion that the stat structure is compliant.
Most of the infrastructure is in place for the enabling it, but I want
to get all the long filename support in first.
What is needed is that the stat/fstat calls will need to cache the
short path and filename being tested in space that is now reserved in
the mystat structure. The perl_cando code will then reference this
instead of a static cache that is used now for both stat and fstat().
At that point, I do not think that the static cache will be needed,
and also after that change, there should be no reason for VMS.C to
track the differences between the two stat structures.
Is it because this feature is not available on the VAX?
No, but it is not available before OpenVMS 8.2 and requires 64 bit
support by the compiler.
It is available on V7.3-2. I don't have anything older than that to |
check. It does require 64-bit file support but that has been around for
quite a while.
Mark Berryman |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Thu Feb 02, 2006 12:42 am Post subject:
Re: patch@26996 - patch around stat("_NLA0:") bug
|
|
|
Mark Berryman wrote:
| Quote: |
It is available on V7.3-2. I don't have anything older than that to
check. It does require 64-bit file support but that has been around
for quite a while.
|
You are right, it showed up in V7.3-2, but since I am not using 7.3-2 on
any of my build/test systems, I was not going to enable it for that
older version since I could not test it. That is why 8.2 was sticking
in my head.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Thu Feb 02, 2006 2:54 pm Post subject:
Re: Compilation problem on AXP for PERL-5_8_8-RC1
|
|
|
At 1:50 PM +0100 2/2/06, Frans Slothouber wrote:
| Quote: | Hoi
I get the following two compilation errors for
5_8_8_RC1
This is under DEC C V5.6-003 on OpenVMS Alpha V7.1-2
|
Thanks for the report. v5.6 is now about a nine-year-old compiler
and I don''t see much value in trying to backport to it, nor do I
have the facilities to do so. v6.4 builds Perl just fine, was the
first version to include significant C99 support, and has been out
for about five or six years. I think that would be a reasonable
minimum version. I wouldn't be surprised if v6.0 and v6.2 also work
ok, but I don't have any way to test that. It would be nice if we
could state with some certainty what the minimum compiler version
needs to be in order to build Perl, but without a much wider array of
build reports, that's not doable.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Frans Slothouber
*nix forums beginner
Joined: 12 Jan 2006
Posts: 5
|
| Posted: Thu Feb 02, 2006 3:11 pm Post subject:
Re: Compilation problem on AXP for PERL-5_8_8-RC1
|
|
|
| Quote: | At 1:50 PM +0100 2/2/06, Frans Slothouber wrote:
Hoi
I get the following two compilation errors for
5_8_8_RC1
This is under DEC C V5.6-003 on OpenVMS Alpha V7.1-2
Thanks for the report. v5.6 is now about a nine-year-old compiler
and I don''t see much value in trying to backport to it, nor do I
have the facilities to do so. v6.4 builds Perl just fine, was the
first version to include significant C99 support, and has been out
for about five or six years. I think that would be a reasonable
minimum version. I wouldn't be surprised if v6.0 and v6.2 also work
ok, but I don't have any way to test that. It would be nice if we
could state with some certainty what the minimum compiler version
needs to be in order to build Perl, but without a much wider array of
build reports, that's not doable.
|
I can provide build reports for:
DEC C V5.6-003 on OpenVMS VAX V7.1
Compaq C V6.4-008 on OpenVMS Alpha V7.1-2
hp C T7.1-003 on OpenVMS IA64 V8.2-1
DEC C V5.6-003 on OpenVMS Alpha V7.1-2
Will ask here how easy it is for us to migrate all systems to
V6.4. If we can't then I don't mind doing the back-porting.
Will report back when there's more info.
Have fun,
Frans. |
|
| Back to top |
|
|
Chris Sharman
*nix forums addict
Joined: 02 Aug 2005
Posts: 83
|
| Posted: Wed Feb 08, 2006 9:12 am Post subject:
Re: build failure 5.84-5.88 SOLVED - test failures ??
|
|
|
Found ancient perl.exe in sys$system - removed it, and all's well.
Well, much better, anyway - 5.8.8 built.
Test results - 10 failures.
I managed to run the first of these, for more details, but the details
didn't mean much to me - should I be worrying ?
System: Alpha VMS 7.3-1, DEC C 6.5-001
Thanks
Chris
t/io/fs...................................FAILED at test 26
ext/Devel/PPPort/t/ppphtest...............FAILED--unexpected output at
test 0
ext/List/Util/t/p_tainted.................FAILED--no leader found
ext/List/Util/t/weak......................FAILED--unexpected output at
test 7
lib/ExtUtils/t/basic......................FAILED at test 67
lib/ExtUtils/t/Command....................FAILED at test 8
lib/ExtUtils/t/FIRST_MAKEFILE.............FAILED at test 4
lib/ExtUtils/t/PL_FILES...................FAILED at test 3
lib/Math/BigInt/t/mbi_rand................FAILED--unexpected output at
test 56
lib/Test/Simple/t/is_deeply_fail..........FAILED at test 73
Failed 10 test scripts out of 892, 98.88% okay.
### Since not all tests were successful, you may want to run some of
### them individually and examine any diagnostic messages they produce.
### See the INSTALL document's section on "make test".
### You have a good chance to get more information by running
### ./perl harness
### in the 't' directory since most (>=80%) of the tests succeeded.
u=493.57 s=0.00 cu=0.00 cs=0.00 scripts=892 tests=114061
7-FEB-2006 21:26:16.42 User: CHRIS Process ID: 20402EC3
Node: CYGNUS Process name: "CHRIS_206"
Accounting information:
Buffered I/O count: 638024 Peak working set size: 9008
Direct I/O count: 159946 Peak virtual size: 175136
Page faults: 17598 Mounted volumes: 0
Images activated: 84
Elapsed CPU time: 0 00:08:13.74
Connect time: 0 03:50:17.74
Soft CPU Affinity: off
%SYSTEM-F-ABORT, abort
$ mc [-]perl io/fs.t
1..42
ok 1 - umask
ok 2 # skip: no link
ok 3 # skip: no link
ok 4 # skip: no link
ok 5 # skip: no link
ok 6 - chmod succeeding
ok 7 # skip: no link
ok 8 # skip: no link
ok 9 # skip: no link
ok 10 # skip: no link
ok 11 # skip: no link
ok 12 # skip: no link
ok 13 # skip: no link
ok 14 # skip: no fchmod
ok 15 # skip: no fchmod
ok 16 # skip: no fchmod
ok 17 # skip: no fchmod
ok 18 # skip: no fchmod
ok 19 # skip: no fchown
ok 20 - fchmod is unimplemented
ok 21 - fchown is unimplemented
ok 22 - rename a b
ok 23 - ino of renamed file a should be undef
ok 24 - utime
ok 25 - non-zero inode num
# atime - 500003601 mtime - 500003601 delta - 1
not ok 26 - atime
# Failed at io/fs.t line 255
# got '500003601'
# expected '500000001'
not ok 27 - mtime
# Failed at io/fs.t line 256
# got '500003601'
# expected '500000001'
ok 28 - unlink b
ok 29 - ino of unlinked file b should be undef
ok 30 # skip: Win32/Netware specific test
ok 31 # skip: Win32/Netware specific test
ok 32 - truncation to five bytes
ok 33 - truncation to zero bytes
ok 34 - fh resize to 200
ok 35 - fh resize to 200 working (filename check)
ok 36 - fh resize to zero
ok 37 - fh resize to zero working (filename check)
ok 38 - fh resize by IO slot
ok 39 - fh resize by IO slot working
ok 40 - rename working
ok 41 - rename on directories
ok 42 - rename on directories working
Any views expressed in this message are those of the sender and not necessarily those of CCA Group. The unauthorized use, disclosure, copying or alteration of this message is forbidden. The contents of this message may be confidential and/or privileged, copyright CCA Group and are intended solely for the use of the individual or entity to whom they are addressed. Whilst this message has been scanned, CCA Group cannot guarantee that it is virus free or compatible with your systems and accepts no responsibility for any loss or damage arising from its use. The recipient is advised to run their own anti-virus software. If you receive this message in error please contact postmaster@ccagroup.co.uk immediately, destroy any copies and delete it from your computer systems. |
|
| Back to top |
|
|
Ken Williams
*nix forums beginner
Joined: 16 Mar 2005
Posts: 6
|
| Posted: Thu Feb 09, 2006 3:56 am Post subject:
Re: P.S. the problem is in catdir
|
|
|
Hi Steven,
On VMS is 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]' an absolute path, i.e. is
the SLEMBARK directory understood to be at the root of the USER volume?
If so, probably splitpath() is actually returning the wrong result.
On other platforms it returns an initial empty string to indicate an
absolute path (it's kind of an historical accident, but now that's just
its semantics):
% perl -MFile::Spec::Functions=:ALL -de1
....
DB<1> x $bin = '/foo/bar/baz';
0 '/foo/bar/baz'
DB<2> x ( $vol, $dir ) = splitpath $bin;
0 ''
1 '/foo/bar/'
DB<3> x @subdirz = splitdir $dir;
0 ''
1 'foo'
2 'bar'
3 ''
DB<4> x $libdir = catdir @subdirz, 'lib';
0 '/foo/bar/lib'
That empty string is the only clue catdir() gets that it should be
forming an absolute path instead of a relative one.
Then we'll need to make sure catdir('', 'SLEMBARK',
'FINDBIN-LIBS-1_20', 'lib') returns the right result too,
'[SLEMBARK.FINDBIN-LIBS-1_20.lib]'.
-Ken
On Feb 8, 2006, at 6:00 PM, Steven Lembark wrote:
| Quote: |
Notice the 6th statement adds a leading '.' to the directory.
DB<1> use File::Spec::Functions qw( splitpath splitdir catpath
catdir );
DB<2> use FindBin;
DB<3> x ( $bin ) = $FindBin::Bin =~ m{(.+)};
0 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]'
DB<4> x ( $vol, $dir ) = splitpath $bin;
0 'USER:'
1 '[SLEMBARK.FINDBIN-LIBS-1_20]'
DB<5> x @subdirz = splitdir $dir;
0 'SLEMBARK'
1 'FINDBIN-LIBS-1_20'
DB<6> x $libdir = catdir @subdirz, 'lib';
0 '[.SLEMBARK.FINDBIN-LIBS-1_20.lib]'
DB<7> x $path = catpath $vol, catdir @subdirz, 'lib';
0 'USER:[.SLEMBARK.FINDBIN-LIBS-1_20.lib]'
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@wrkhors.com 1 888 359 3508 |
|
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Thu Feb 09, 2006 2:49 pm Post subject:
Re: build failure 5.84-5.88 SOLVED - test failures ??
|
|
|
At 9:12 AM +0000 2/8/06, Chris Sharman wrote:
| Quote: | Found ancient perl.exe in sys$system - removed it, and all's well.
|
You might have had PERL5LIB or PERLLIB logical names defined that
caused the Perl being built to look for modules in an existing Perl.
I build Perl all the time on systems that already have Perl, but I've
never had trouble with the two getting confused with each other.
| Quote: | Well, much better, anyway - 5.8.8 built.
Test results - 10 failures.
I managed to run the first of these, for more details, but the details
didn't mean much to me - should I be worrying ?
System: Alpha VMS 7.3-1, DEC C 6.5-001
|
Most of these are expected and are documented here:
http://perldoc.perl.org/perl588delta.html#Platform-Specific-Problems
Whether to worry about them really depends on whether they are
testing features that you will depend on. The chances of that seem
pretty small, though, given that only a handful of tests failed out
of well over 100,000.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Steven Lembark
*nix forums beginner
Joined: 09 Feb 2006
Posts: 5
|
| Posted: Thu Feb 09, 2006 5:17 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
-- Ken Williams <ken@mathforum.org>
| Quote: | Hi Steven,
On VMS is 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]' an absolute path, i.e. is
the SLEMBARK directory understood to be at the root of the USER volume?
If so, probably splitpath() is actually returning the wrong result. On
other platforms it returns an initial empty string to indicate an
absolute path (it's kind of an historical accident, but now that's just
its semantics):
|
Yes. On VMS dir's referenced under a logical volume are
absolute to that volume.
What is interesting is that
my ( $vol, $bin ) = splitpath $Bin;
my @subdirz = splitdir $bin;
my $path = catpath $vol, catdir @subdirz, 'lib';
goes from
USER:[SLEMBARK.FINDBIN-LIBS-1_20]
to
USER:[.SLEMBARK.FINDBIN-LIBS-1_20.lib]
which adds a relative path (leading '.') an input dir
that originally did not have one.
Until I use abs_path to try and resolve the logical volume
(which may be a search list) into a physical volume,
it should be opaque.
| Quote: | % perl -MFile::Spec::Functions=:ALL -de1
...
DB<1> x $bin = '/foo/bar/baz';
0 '/foo/bar/baz'
DB<2> x ( $vol, $dir ) = splitpath $bin;
0 ''
1 '/foo/bar/'
DB<3> x @subdirz = splitdir $dir;
0 ''
1 'foo'
2 'bar'
3 ''
DB<4> x $libdir = catdir @subdirz, 'lib';
0 '/foo/bar/lib'
That empty string is the only clue catdir() gets that it should be
forming an absolute path instead of a relative one.
Then we'll need to make sure catdir('', 'SLEMBARK', 'FINDBIN-LIBS-1_20',
'lib') returns the right result too, '[SLEMBARK.FINDBIN-LIBS-1_20.lib]'.
|
Then the problem was splitdir '[SLEMBARK.blah]' returning
without a leading ''.
This gives me a fix for the moment at least: I can unshift
a leading '' into @subdirz since $FindBin::Bin is always
supposed to be an absolute path.
thanx
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@wrkhors.com 1 888 359 3508 |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Thu Feb 09, 2006 7:43 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
At 9:56 PM -0600 2/8/06, Ken Williams wrote:
| Quote: | Hi Steven,
On VMS is 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]' an absolute path, i.e. is the SLEMBARK directory understood to be at the root of the USER volume?
|
Yes. You would not see the volume name if it weren't an absolute path.
| Quote: | If so, probably splitpath() is actually returning the wrong result. On other platforms it returns an initial empty string to indicate an absolute path (it's kind of an historical accident, but now that's just its semantics):
|
The documentation states that the first item returned is the volume,
and "On systems with no concept of volume, returns '' for volume." I
would take this to mean that the volume would be an empty string on,
for example, unix, regardless of whether the path is relative or
absolute. On VMS, it returns the empty string for the volume when
there is no volume in the input parameter, i.e., the path is relative.
Perhaps I'm misunderstanding something, but I can't see how an empty
volume name could ever indicate an absolute path.
| Quote: |
% perl -MFile::Spec::Functions=:ALL -de1
...
DB<1> x $bin = '/foo/bar/baz';
0 '/foo/bar/baz'
DB<2> x ( $vol, $dir ) = splitpath $bin;
0 ''
1 '/foo/bar/'
DB<3> x @subdirz = splitdir $dir;
0 ''
1 'foo'
2 'bar'
3 ''
DB<4> x $libdir = catdir @subdirz, 'lib';
0 '/foo/bar/lib'
That empty string is the only clue catdir() gets that it should be forming an absolute path instead of a relative one.
|
Perhaps on VMS, splitdir should do the same thing splitpath does and
return the volume as the first element. I'm concerned about what
that might break, though.
| Quote: |
Then we'll need to make sure catdir('', 'SLEMBARK', 'FINDBIN-LIBS-1_20', 'lib') returns the right result too, '[SLEMBARK.FINDBIN-LIBS-1_20.lib]'.
-Ken
On Feb 8, 2006, at 6:00 PM, Steven Lembark wrote:
Notice the 6th statement adds a leading '.' to the directory.
DB<1> use File::Spec::Functions qw( splitpath splitdir catpath catdir );
DB<2> use FindBin;
DB<3> x ( $bin ) = $FindBin::Bin =~ m{(.+)};
0 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]'
DB<4> x ( $vol, $dir ) = splitpath $bin;
0 'USER:'
1 '[SLEMBARK.FINDBIN-LIBS-1_20]'
DB<5> x @subdirz = splitdir $dir;
0 'SLEMBARK'
1 'FINDBIN-LIBS-1_20'
DB<6> x $libdir = catdir @subdirz, 'lib';
0 '[.SLEMBARK.FINDBIN-LIBS-1_20.lib]'
DB<7> x $path = catpath $vol, catdir @subdirz, 'lib';
0 'USER:[.SLEMBARK.FINDBIN-LIBS-1_20.lib]'
|
Passing a list of directory names to catdir is always going to return
a relative path. The only way I know of to make clear you want an
absolute path is to include the volume name:
DB<13> x ($vol,$dir) = splitpath('dev:[foo.bar.baz]')
0 'dev:'
1 '[foo.bar.baz]'
DB<14> x @dirs = splitdir $dir
0 'foo'
1 'bar'
2 'baz'
DB<15> x $rejoin = catdir($vol, @dirs)
0 'dev:[foo.bar.baz]'
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
Ken Williams
*nix forums beginner
Joined: 16 Mar 2005
Posts: 6
|
| Posted: Thu Feb 09, 2006 8:47 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
On Feb 9, 2006, at 1:43 PM, Craig A. Berry wrote:
| Quote: | At 9:56 PM -0600 2/8/06, Ken Williams wrote:
Hi Steven,
On VMS is 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]' an absolute path, i.e.
is the SLEMBARK directory understood to be at the root of the USER
volume?
Yes. You would not see the volume name if it weren't an absolute path.
|
So on VMS there's no equivalent of the Windows pathname "C:Foo\Bar",
which means "the Foo\Bar directory relative to whatever the C drive's
current working directory is"?
| Quote: | If so, probably splitpath() is actually returning the wrong result.
On other platforms it returns an initial empty string to indicate an
absolute path (it's kind of an historical accident, but now that's
just its semantics):
The documentation states that the first item returned is the volume,
and "On systems with no concept of volume, returns '' for volume." I
would take this to mean that the volume would be an empty string on,
for example, unix, regardless of whether the path is relative or
absolute. On VMS, it returns the empty string for the volume when
there is no volume in the input parameter, i.e., the path is relative.
Perhaps I'm misunderstanding something, but I can't see how an empty
volume name could ever indicate an absolute path.
|
Ack, sorry, I meant to say splitdir(), not splitpath().
-Ken |
|
| Back to top |
|
|
Steven Lembark
*nix forums beginner
Joined: 09 Feb 2006
Posts: 5
|
| Posted: Thu Feb 09, 2006 10:20 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
| Quote: | Perhaps I'm misunderstanding something, but I can't see how an empty
volume name could ever indicate an absolute path.
|
Because on *NIX you can
join '/', @subdirz;
and get a leading '/'.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@wrkhors.com 1 888 359 3508 |
|
| Back to top |
|
|
Steven Lembark
*nix forums beginner
Joined: 09 Feb 2006
Posts: 5
|
| Posted: Thu Feb 09, 2006 10:23 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
| Quote: | Perhaps on VMS, splitdir should do the same thing splitpath does and
return the volume as the first element. I'm concerned about what
that might break, though.
|
Catch: the volume is not part of the directory.
If you want to split that off use splitpath.
If the interface were OO then it could return a
blessed-list-of-subdirs with an absolute/relative
flag buried in it.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@wrkhors.com 1 888 359 3508 |
|
| Back to top |
|
|
Steven Lembark
*nix forums beginner
Joined: 09 Feb 2006
Posts: 5
|
| Posted: Thu Feb 09, 2006 10:36 pm Post subject:
Re: P.S. the problem is in catdir
|
|
|
-- Ken Williams <ken@mathforum.org>
| Quote: |
On Feb 9, 2006, at 1:43 PM, Craig A. Berry wrote:
At 9:56 PM -0600 2/8/06, Ken Williams wrote:
Hi Steven,
On VMS is 'USER:[SLEMBARK.FINDBIN-LIBS-1_20]' an absolute path, i.e.
is the SLEMBARK directory understood to be at the root of the USER
volume?
Yes. You would not see the volume name if it weren't an absolute path.
So on VMS there's no equivalent of the Windows pathname "C:Foo\Bar",
which means "the Foo\Bar directory relative to whatever the C drive's
current working directory is"?
|
On vms you can have a leading '.' that designates a directory
relative to the default. There is no notion of a 'working'
directory on VMS in that sense. You have the "default" set
via "set def" used to fill in portions of the path not
provided on the command.
For example:
$ set def sys$login:
$ set def [SANDBOX]
$ show def
gives me a default of whatever "sys$login:" is aliased to
with a subdir of "SANDBOX". But the "show def" will always
give me an absolute path since the default will be used by
DCL to fill in any missing portinos of the path.
A leading '.' designates the path as relative to the current
default.
In other words:
$ set def USER:[SLEMBARK]
$ set def [.SANDBOX]
is converted by DCL into
$ set def USER:[SLEMBARK.SANDBOX]
which is an absolute path. Net result is that relative paths
are converted on the fly to absoute ones using the current
default value loaded via "set default".
This replaces the *NIX notion of "working directory" with
one of a "current default" that is used to convert relative
paths into absolute ones.
This matters on VMS becuase the volume portion can be all
sorts of things, including search lists, all of which are
opaque to the caller. This allows me to
set def USER$SANDBOX:
and later
set def [FOOBAR]
and end up in USER:[PROJECTS.SANDBOX.INWORK.FOOBAR] becuase
VMS checked in the eight dir's defined as user$sandbox: and
the first one with a 'FOOBAR' subdir became my new default.
--
Steven Lembark 85-09 90th Street
Workhorse Computing Woodhaven, NY 11421
lembark@wrkhors.com 1 888 359 3508 |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 5:24 am | All times are GMT
|
|
Car salvage | Computeach | Loans | Cheapest mobile phones | Bad Credit Mortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
»
vmsperl
