[Info-vax] bug with DIRECTORY and search lists

[David J Dachtera]

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.

Well, my guess is that this the expected behavior, and probably works
the same way using F$SEARCH() in DCL.

About the only explanation I can think of would center on the concept
behind DIRECTORY: it is used to list out DIRECTORIES, not necessarily
the files in them.

Perhaps if there had always been, for example, a F(ILE)LIST (FLIST)
command which read INDEXF.SYS instead using a wildcard spec. of "*.*;*"
by default, and then reported the path to the file - perhaps as well as
the usual stat.'s - optionally sorted alphabetically by decreasing
version number (which we're all accustomed to) then we'd be talking
about a different critter  - altogther.

All: "We'd be talking about a different critter."

(...with a nod to the Zuckers, and their movie, "Airplane".)

I supposed one could have envisioned a /VOLUME qualifier which one might
use like so:

$ FLIST/VOLUME=*$D*:/FID/NAME/TYPE/VERSION/SORT=NAME,TYPE,-VERSION/PATH-
/SIZE=ALL/PROTECTION/PATH/DATE=CREATED

...where everything except "/VOLUME=*$D*:" and
"/SIZE=ALL/PROTECTION/DATE=CREATED" are the defaults. /VOLUME would
default would be determined by P1. If P1 contained a logical or device
name, that would determine which volume would be searched.
"/VOLUME=*$D*:" would result in every volume disk currently MOUNTed to
the system being searched ($alloclass$Ddcu or nodename$Ddcu:).

For example:

$ SHOW DEFAULT
  USER_DISK:[USER.DDACHTERA]
$ FLIST LOGIN.COM

Files matching LOGIN.COM:

(1476,7,0)      LOGIN.COM;7              USER_DISK:[USER.DDACHTERA]
(1423,4,0)      LOGIN.COM;6              USER_DISK:[USER.DDACHTERA]
(1237,16,0)     LOGIN.COM;6              USER_DISK:[USER.KCONNOLLY]
(1423,1,0)      LOGIN.COM;2              USER_DISK:[USER.DCUTLER]


 4 files found.

...assuming at least one match is found.

Might have been useful in VMS's history.

D.J.D.