Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread John E. Malmberg

Craig A. Berry wrote:


On Dec 7, 2008, at 12:46 PM, John E. Malmberg wrote:


Point taken,

Attached is vms/ext/filespec.t that changes those tests to be passing.


The documentation for VMS::Filespec::pathify says, "the file type and 
version, if specified, must be .DIR;1. For compatibility with Unix 
usage, the type and version may also be omitted."  The tests have 
enforced this behavior since before 5.004.  You're proposing to change 
the behavior so that a file type that is not .DIR is no longer 
considered a file type at all and the dot would then be considered part 
of the filename rather than the start of the type field.  That could 
easily break existing code and doesn't seem to me like the way to go.


This is for UNIX format file specifications, which normally should not 
have a .dir on them when they are directories.


The new behavior is not inconsistent with the existing documentation, 
except that the old routine does not work for EFS characters.


Now if the dot is escaped and is thus unambiguously just an actual dot 
rather than a directory or file type delimiter that's a different 
story.  We should support and test for those cases, something like:


__path_^.actualdot pathify __path_.actualdot/


The '^' escape character is only present on VMS format file 
specifications.  With out any directory delimiter characters present, 
pathify assumes that this is a UNIX directory.


With a Unix directory syntax if ".DIR" is not present, the behavior of 
pathify would normally to be just put a '/' on the specification. 
Removing the ".dir" is needed because it may be present.


The following demonstrates the existing behavior is inconsistent:

$ perl -v

This is perl, v5.10.0 built for VMS_AXP

$ perl -e "print VMS::Filespec::vmsify('foo/bar./')"
[.foo.bar_]
$

$ perl -e "print VMS::Filespec::vmspath('foo/bar.')"
$
[Nothing output]

Those two sample one liners should have produced the same output.

$ define decc$efs_charset ENABLE
$ perl -e "print VMS::Filespec::vmsify('foo/bar./')"
[.foo.bar^.]

$ perl -e "print VMS::Filespec::vmspath('foo/bar.')"
$
[Nothing output]

As should these two examples.

So while it is change in behavior, the older tested behavior appears to 
be incorrect as it will cause file specifications that are accepted in 
other routines to be rejected.


I do not think this would be noticed in existing programs other than the 
test routines because such file specifications are rare on a VMS system, 
and that if someone had encountered one of them, they would have had to 
modify their perl program to not use pathify, unixpath, or vmspath.


-John
[EMAIL PROTECTED]
Personal Opinion Only


Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread Craig A. Berry


On Dec 7, 2008, at 12:46 PM, John E. Malmberg wrote:


Nicholas Clark wrote:

On Sun, Dec 07, 2008 at 08:46:52AM -0600, John E. Malmberg wrote:
An additional note, this patch may cause some tests in vmsfspec.t  
to fail.  That is because the old behavior of pathfiy_dirspec()  
was inconsistent with vmsify().

On Sun, Dec 07, 2008 at 10:15:39AM -0600, John E. Malmberg wrote:
This is all needed for me to proceed with the testing of VMS perl  
in a UNIX compatible mode.  Currently most of the tests are passing.
My view (and on matters VMS specific I'm going to defer to Craig,  
if he
differs) is that if a needed change temporarily makes a known  
subset of
tests fail, then it should include a patch to make exactly those  
tests

TODO tests.


I don't differ, except what I think we're seeing here is a change in  
behavior, not temporary TODOs.



Point taken,

Attached is vms/ext/filespec.t that changes those tests to be passing.


The documentation for VMS::Filespec::pathify says, "the file type and  
version, if specified, must be .DIR;1. For compatibility with Unix  
usage, the type and version may also be omitted."  The tests have  
enforced this behavior since before 5.004.  You're proposing to change  
the behavior so that a file type that is not .DIR is no longer  
considered a file type at all and the dot would then be considered  
part of the filename rather than the start of the type field.  That  
could easily break existing code and doesn't seem to me like the way  
to go.


Now if the dot is escaped and is thus unambiguously just an actual dot  
rather than a directory or file type delimiter that's a different  
story.  We should support and test for those cases, something like:


__path_^.actualdot pathify __path_.actualdot/



--- /rsync_root/perl/vms/ext/filespec.t Thu Mar 15 20:43:30 2007
+++ /ref1_root/perl/vms/ext/filespec.t  Sun Dec  7 12:35:53 2008
@@ -100,14 +100,14 @@
__down_:[__the_.__garden_]__path_  pathify __down_: 
[__the_.__garden_.__path_]
__down_:[__the_.__garden_]__path_. pathify # N.B. trailing . ==>  
null type

__down_:[__the_]__garden_.__path_  pathify undef
-/__down_/__the_/__garden_/__path_. pathify # N.B. trailing .  
==> null type

-/__down_/__the_/__garden_.__path_  pathify undef
+/__down_/__the_/__garden_/__path_. pathify /__down_/__the_/ 
__garden_/__path__/
+/__down_/__the_/__garden_.__path_  pathify /__down_/__the_/ 
__gardenpath_/

__down_:[__the_.__garden_]__path_.dir;2pathify #N.B. ;2
__path_pathify __path_/
/__down_/__the_/__garden_/.pathify /__down_/__the_/__garden_/./
/__down_/__the_/__garden_/..   pathify /__down_/__the_/__garden_/../
/__down_/__the_/__garden_/...  pathify /__down_/__the_/__garden_/.../
-__path_.notdir pathify undef
+__path_.notdir pathify __path__notdir/

# Both VMS/Unix and file/path conversions
__down_:[__the_.__garden_]__path_.dir;1unixpath/ 
__down_/__the_/__garden_/__path_/



Craig A. Berry
mailto:[EMAIL PROTECTED]

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



Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread John E. Malmberg

Nicholas Clark wrote:

On Sun, Dec 07, 2008 at 08:46:52AM -0600, John E. Malmberg wrote:


An additional note, this patch may cause some tests in vmsfspec.t to 
fail.  That is because the old behavior of pathfiy_dirspec() was 
inconsistent with vmsify().



On Sun, Dec 07, 2008 at 10:15:39AM -0600, John E. Malmberg wrote:


This is all needed for me to proceed with the testing of VMS perl in a 
UNIX compatible mode.  Currently most of the tests are passing.



My view (and on matters VMS specific I'm going to defer to Craig, if he
differs) is that if a needed change temporarily makes a known subset of
tests fail, then it should include a patch to make exactly those tests
TODO tests.


Point taken,

Attached is vms/ext/filespec.t that changes those tests to be passing.

A more complete version will come once I make sure that everything is ok 
in the UNIX and extended file system support.


-John
[EMAIL PROTECTED]
Personal Opinion Only


--- /rsync_root/perl/vms/ext/filespec.t Thu Mar 15 20:43:30 2007
+++ /ref1_root/perl/vms/ext/filespec.t  Sun Dec  7 12:35:53 2008
@@ -100,14 +100,14 @@
 __down_:[__the_.__garden_]__path_  pathify 
__down_:[__the_.__garden_.__path_]
 __down_:[__the_.__garden_]__path_. pathify # N.B. trailing . ==> null type
 __down_:[__the_]__garden_.__path_  pathify undef
-/__down_/__the_/__garden_/__path_. pathify # N.B. trailing . ==> null type
-/__down_/__the_/__garden_.__path_  pathify undef
+/__down_/__the_/__garden_/__path_. pathify 
/__down_/__the_/__garden_/__path__/
+/__down_/__the_/__garden_.__path_  pathify 
/__down_/__the_/__gardenpath_/
 __down_:[__the_.__garden_]__path_.dir;2pathify #N.B. ;2
 __path_pathify __path_/
 /__down_/__the_/__garden_/.pathify /__down_/__the_/__garden_/./
 /__down_/__the_/__garden_/..   pathify /__down_/__the_/__garden_/../
 /__down_/__the_/__garden_/...  pathify /__down_/__the_/__garden_/.../
-__path_.notdir pathify undef
+__path_.notdir pathify __path__notdir/
 
 # Both VMS/Unix and file/path conversions
 __down_:[__the_.__garden_]__path_.dir;1unixpath
/__down_/__the_/__garden_/__path_/


Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread John E. Malmberg

Craig A. Berry wrote:


On Dec 7, 2008, at 8:46 AM, John E. Malmberg wrote:

An additional note, this patch may cause some tests in vmsfspec.t to 
fail.  That is because the old behavior of pathfiy_dirspec() was 
inconsistent with vmsify().




Specifically:

not ok 92 - pathify('/__down_/__the_/__garden_/__path_.'): 
'/__down_/__the_/__garden_/__path__/'

# Failed at [.lib]vmsfspec.t line 24
#  got '/__down_/__the_/__garden_/__path__/'
# expected ''
...
not ok 94 - pathify('/__down_/__the_/__garden_.__path_'): 
'/__down_/__the_/__gardenpath_/'

# Failed at [.lib]vmsfspec.t line 24
#  got '/__down_/__the_/__gardenpath_/'
# expected ''
...
not ok 106 - pathify('__path_.notdir'): '__path__notdir/'
# Failed at [.lib]vmsfspec.t line 24
#  got '__path__notdir/'
# expected ''

I am working on a new version of vmssfspec.t that handles both the 
traditional mode of perl and with the decc$efs_charset / 
decc$filename_unix_report modes activated.



How does this plan address the failures above?


The "got" results will be come the expected results.

This is needed to make the handling of dots in directories consistent 
with what vmsify does when it encounters a dot in a directory path.


See the results of vmsify($unixpath . '/') where $unixpath is not '' for
the same inputs.


It is also needed for better handling of symbolic links which act like 
directories and but are not named .dir.


-John
[EMAIL PROTECTED]
Personal Opinion Only


Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread Nicholas Clark
On Sun, Dec 07, 2008 at 08:46:52AM -0600, John E. Malmberg wrote:

> An additional note, this patch may cause some tests in vmsfspec.t to 
> fail.  That is because the old behavior of pathfiy_dirspec() was 
> inconsistent with vmsify().

On Sun, Dec 07, 2008 at 10:15:39AM -0600, John E. Malmberg wrote:

> This is all needed for me to proceed with the testing of VMS perl in a 
> UNIX compatible mode.  Currently most of the tests are passing.

My view (and on matters VMS specific I'm going to defer to Craig, if he
differs) is that if a needed change temporarily makes a known subset of
tests fail, then it should include a patch to make exactly those tests
TODO tests.

Else, whoever wants to apply it, or look at the code afterwards, has no idea
whether the tests they see failing are "expected" or "unexpected".

If they don't know that tests are expected to fail, they waste time reporting
things that are actually known to be that way (temporarily)

And if they do know that tests are expected to fail, then they don't report
failures even if they are in unrelated areas.


Hence why I'd much prefer the list of "these are expected to fail", and that
list to be supplied in code form.

Nicholas Clark


Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread Craig A. Berry


On Dec 7, 2008, at 8:46 AM, John E. Malmberg wrote:


John E. Malmberg wrote:
The mp_do_pathify_dirspec needed enhancements to more accurately  
parse VMS file specifications, and also to handle UNIX file  
specifications the same way that mp_do_tovmspath() does.

It was simpler to replace than to try to modify the existing routine.
In addition this is the start of fixing issues where routines can  
be called with a null thread context, by removing the thread  
context where it is not needed.

More patches will be following this.


An additional note, this patch may cause some tests in vmsfspec.t to  
fail.  That is because the old behavior of pathfiy_dirspec() was  
inconsistent with vmsify().




Specifically:

not ok 92 - pathify('/__down_/__the_/__garden_/__path_.'): '/__down_/ 
__the_/__garden_/__path__/'

# Failed at [.lib]vmsfspec.t line 24
#  got '/__down_/__the_/__garden_/__path__/'
# expected ''
...
not ok 94 - pathify('/__down_/__the_/__garden_.__path_'): '/__down_/ 
__the_/__gardenpath_/'

# Failed at [.lib]vmsfspec.t line 24
#  got '/__down_/__the_/__gardenpath_/'
# expected ''
...
not ok 106 - pathify('__path_.notdir'): '__path__notdir/'
# Failed at [.lib]vmsfspec.t line 24
#  got '__path__notdir/'
# expected ''

I am working on a new version of vmssfspec.t that handles both the  
traditional mode of perl and with the decc$efs_charset / decc 
$filename_unix_report modes activated.




How does this plan address the failures above?

Craig A. Berry
mailto:[EMAIL PROTECTED]

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



Re: [patch@35050] replace pathify_dirspec in VMS with new version

2008-12-07 Thread John E. Malmberg

John E. Malmberg wrote:
The mp_do_pathify_dirspec needed enhancements to more accurately parse 
VMS file specifications, and also to handle UNIX file specifications the 
same way that mp_do_tovmspath() does.


It was simpler to replace than to try to modify the existing routine.

In addition this is the start of fixing issues where routines can be 
called with a null thread context, by removing the thread context where 
it is not needed.


More patches will be following this.


An additional note, this patch may cause some tests in vmsfspec.t to 
fail.  That is because the old behavior of pathfiy_dirspec() was 
inconsistent with vmsify().


I am working on a new version of vmssfspec.t that handles both the 
traditional mode of perl and with the decc$efs_charset / 
decc$filename_unix_report modes activated.


-John
[EMAIL PROTECTED]
Personal Opinion Only


[patch@35050] replace pathify_dirspec in VMS with new version

2008-12-06 Thread John E. Malmberg
The mp_do_pathify_dirspec needed enhancements to more accurately parse 
VMS file specifications, and also to handle UNIX file specifications the 
same way that mp_do_tovmspath() does.


It was simpler to replace than to try to modify the existing routine.

In addition this is the start of fixing issues where routines can be 
called with a null thread context, by removing the thread context where 
it is not needed.


More patches will be following this.

-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/vms/vms.c  Fri Dec  5 12:13:19 2008
+++ vms/vms.c   Sat Dec  6 03:31:43 2008
@@ -362,6 +362,40 @@
 int decc_dir_barename = 0;
 
 static int vms_debug_on_exception = 0;
+static int vms_debug_fileify = 0;
+
+
+/* Simple logical name translation */
+static int simple_trnlnm
+   (const char * logname,
+char * value,
+int value_len)
+{
+const $DESCRIPTOR(table_dsc, "LNM$FILE_DEV");
+const unsigned long attr = LNM$M_CASE_BLIND;
+struct dsc$descriptor_s name_dsc;
+int status;
+unsigned short result;
+struct itmlst_3 itlst[2] = {{value_len, LNM$_STRING, value, &result},
+{0, 0, 0, 0}};
+
+name_dsc.dsc$w_length = strlen(logname);
+name_dsc.dsc$a_pointer = (char *)logname;
+name_dsc.dsc$b_dtype = DSC$K_DTYPE_T;
+name_dsc.dsc$b_class = DSC$K_CLASS_S;
+
+status = sys$trnlnm(&attr, &table_dsc, &name_dsc, 0, itlst);
+
+if ($VMS_STATUS_SUCCESS(status)) {
+
+/* Null terminate and return the string */
+   /*--*/
+   value[result] = 0;
+return result;
+}
+
+return 0;
+}
 
 /* Is this a UNIX file specification?
  *   No longer a simple check with EFS file specs
@@ -888,6 +922,27 @@
 }
 
 
+/* Routine to determine if the file specification ends with .dir */
+static int is_dir_ext(char * e_spec, int e_len, char * vs_spec, int vs_len) {
+
+/* e_len must be 4, and version must be <= 2 characters */
+if (e_len != 4 || vs_len > 2)
+return 0;
+
+/* If a version number is present, it needs to be one */
+if ((vs_len == 2) && (vs_spec[1] != '1'))
+return 0;
+
+/* Look for the DIR on the extension */
+if ((toupper(e_spec[1]) == 'D') &&
+(toupper(e_spec[2]) == 'I') &&
+(toupper(e_spec[3]) == 'R')) {
+return 1;
+}
+return 0;
+}
+
+
 /* my_maxidx
  * Routine to retrieve the maximum equivalence index for an input
  * logical name.  Some calls to this routine have no knowledge if
@@ -6236,280 +6291,434 @@
 char *Perl_fileify_dirspec_utf8_ts(pTHX_ const char *dir, char *buf, int * 
utf8_fl)
 { return do_fileify_dirspec(dir,buf,1,utf8_fl); }
 
-/*{{{ char *pathify_dirspec[_ts](char *path, char *buf)*/
-static char *mp_do_pathify_dirspec(pTHX_ const char *dir,char *buf, int ts, 
int * utf8_fl)
-{
-static char __pathify_retbuf[VMS_MAXRSS];
-unsigned long int retlen;
-char *retpath, *cp1, *cp2, *trndir;
+static char * int_pathify_dirspec_simple(const char * dir, char * buf,
+char * v_spec, int v_len, char * r_spec, int r_len,
+char * d_spec, int d_len, char * n_spec, int n_len,
+char * e_spec, int e_len, char * vs_spec, int vs_len) {
+
+/* VMS specification - Try to do this the simple way */
+if ((v_len + r_len + d_len) > 0) {
+int is_dir;
+
+/* No name or extension component, already a directory */
+if ((n_len + e_len + vs_len) == 0) {
+strcpy(buf, dir);
+return buf;
+}
+
+/* Special case, we may get [.foo]bar instead of [.foo]bar.dir */
+/* This results from catfile() being used instead of catdir() */
+/* So even though it should not work, we need to allow it */
+
+/* If this is .DIR;1 then do a simple conversion */
+is_dir = is_dir_ext(e_spec, e_len, vs_spec, vs_len);
+if (is_dir || (e_len == 0)) {
+ int len;
+ len = v_len + r_len + d_len - 1;
+ char dclose = d_spec[d_len - 1];
+ strncpy(buf, dir, len);
+ buf[len] = '.';
+ len++;
+ strncpy(&buf[len], n_spec, n_len);
+ len += n_len;
+ buf[len] = dclose;
+ buf[len + 1] = '\0';
+ return buf;
+}
+
+#ifdef HAS_SYMLINK
+else {
+/* In the olden days, a directory needed to have a .DIR */
+/* extension to be a valid directory, but now it could  */
+/* be a symbolic link */
+int len;
+len = v_len + r_len + d_len - 1;
+char dclose = d_spec[d_len - 1];
+strncpy(buf, dir, len);
+buf[len] = '.';
+len++;
+strncpy(&buf[len], n_spec, n_len);
+len += n_len;
+if (e_len > 0) {
+if (decc_efs_charset) {
+buf[len] = '^';
+len++;
+strncpy(&buf[len], e_spec, e_len);
+