[Info-vax] bug with DIRECTORY and search lists

[AEF]

On Nov 6, 2:44 pm, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> This has been around for a while, I think.  I think there are no plans
> to fix it.  Anyone whose code RELIES on this buggy behaviour deserves to
> have it break.  Presumably, correcting the bug would have side effects
> which would break reasonable code.
>
> Can anyone comment on WHY this "works" as it does?
>
> ---------8<-------------------------------------------------------------------
> $  CREATE/DIRECTORY [.A]
> $  CREATE/DIRECTORY [.B]
> $  CREATE/DIRECTORY [.C]
> $  CREATE/DIRECTORY [.D]
> $  CREATE/DIRECTORY [.Z]
> $  CREATE [.A]A.A
> $  CREATE [.B]B.B
> $  CREATE [.C]C.C
> $  CREATE [.D]D.D
> $  DIRECTORY/NOHEADER/EXCLUDE=*.DIR [...]
> $  DEFINE/NOLOG AAA [.A],[.Z]
> $  DEFINE/NOLOG BBB [.B],[.Z]
> $  DEFINE/NOLOG CCC [.C],[.Z]
> $  DEFINE/NOLOG DDD [.D],[.Z]
> $  DIRECTORY/NOHEADER AAA
> $  DIRECTORY/NOHEADER BBB
> $  DIRECTORY/NOHEADER CCC
> $  DIRECTORY/NOHEADER DDD
> $  TYPE SYS$INPUT
>
> So far, so good!
>
> If the DIRECTORY command specifies a list of logical names, each of
> which is a search list, then if N is the position in the list, the
> contents are listed 2**(N-1) times!
>
> $  SET VERIFY
> $  DIRECTORY/NOHEADER AAA,BBB,CCC,DDD
> $  DIRECTORY/NOHEADER BBB,AAA
> $  EXIT $STATUS + 0*'F$VERIFY(0)'
> ---------8<-------------------------------------------------------------------
>
> If some of the logical names are search lists and some are not, then the
> behaviour is much more complicated.  This is left as an exercise to the
> reader.
>
> It doesn't seem to matter if the search list specifies just two
> directories or more than two directories.
>
> (Note that no files are contained in more than one search list.)
>
> The /VERSION qualifier can be used to reduce the number of lines of
> output, but it acts on lines of output, not on file version numbers.

Phillip,

What's happening here is that RMS is doing sticky defaults. Since BBB
is missing disk, filename, and type fields, RMS matches all possible
values of SYS$DISK from the previous file-spec, AAA. That makes
duplicates. Then the dupes are applied to CCC creating another
doubling. And so on. That's how it works. INAB, IAF! A, IASE: I
surmise that this is just a relatively unimportant side effect of how
RMS works. Not to worry. It's not going to be "fixed".

    >----o----<

This is actually quasi-documented (well -- to be honest --
incompletely, and rather lightly, documented in the User's Manual:

>From http://www.openvms.compaq.com/doc/731final/6489/6489pro_027.html#mod_log_name_trans
:

11.7.1 Using Search Lists with Commands That Accept Wildcards

You can use a search list with a command that accepts wildcards. When
you use wildcards, the system forms file specifications by using each
equivalence string in the search list. The command operates on each
file specification that identifies an existing file.

In the following example, the DIRECTORY command is specified with a
wildcard character in the version field. It finds all versions of
SPEECH.TXT in the search list defined by GETTYSBURG:


$ DIRECTORY GETTYSBURG:SPEECH.TXT;*

Directory DISK1:[JONES.HISTORY]

SPEECH.TXT;2     SPEECH.TXT;1

Total of 2 files.

Directory DISK1:[JONES.WORKFILES]

SPEECH.TXT;1

Total of 1 file.

Grand total of 2 directories, 3 files.

When you enter a search list (for example, using the DIRECTORY
command), the operating system uses elements in one part of the list
to supply parts of the file specification that are omitted from other
parts of the list. If a file specification is not complete (as shown
by SYS$LOGIN in the following example), command lines can produce
multiple files and file-not-found conditions:


$ DIRECTORY SYS$MANAGER:LOGIN.COM,SYS$LOGIN

You can avoid producing multiple files and file-not-found conditions
by placing a semicolon after the file specification, as shown:


$ DIRECTORY SYS$MANAGER:LOGIN.COM;,SYS$LOGIN

    >----o----<

Life is actually even more complicated:

Here are parts 3 and 4 of my efforts to make more sense of all this:

Take 3:

Consider the command "$ DIRECTORY fs_1, fs_2, ...". For each fs_n, if
any fields are missing, they are filled with the value of the
corresponding field of the previous fs_n. For fs_1, missing device and
directory fields are filled by values from the default device and
directory. So if the default device is a search list, it is applied
once for each element in the list to fs_1 is the directory field of
fs_1 is blank. For fs_2 and subsequent elements, if any fields are
missing, they are filled by values from the previous element. If the
previous element's device is a search list (or if was blank and filled
with a search list) then the previous element's values are applied as
defaults once for each equivalence name in the search list, resulting
in files in the current fs_n being listed multiple times, once for
each resultant equivalence name from fs_n-1. Once all fields have
obtained values from the current or any of the previous elements,
files are no longer listed multiple times.

Take 4:

OK, there are still odd exceptions to what I described above. I give
up. If any fields are missing from a file-spec in a command like
"DIRECTORY fs_1, fs_2, ..., and either the default or one of the file-
specs prior to the one in question contain a search string logical
name, then you may get files from that file-spec listed multiple
times.

My advice: Take note . . . and move on.

AEF