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 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.

On Nov 6, 2:44 pm, hel...@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

In article
<a22d5e50-e880-425b-9c93-252e27fa401d@g23g2000yqh.googlegroups.com>, AEF
<spamsink2001@yahoo.com> writes: 

> 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 might be assumed from the example above, but I first saw the 
command with logicals which were defined as DISK:[DIR], so each logical 
name was a full path.

> $ 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.

OK, but I had two ;1 in the same directory.

On Nov 16, 5:33 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article
> <a22d5e50-e880-425b-9c93-252e27fa4...@g23g2000yqh.googlegroups.com>, AEF
>
> <spamsink2...@yahoo.com> writes:
> > 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 might be assumed from the example above, but I first saw the
> command with logicals which were defined as DISK:[DIR], so each logical
> name was a full path.

It does this if *any* field (including name, type, and version number)
is left blank or contains an asterisk. It also supplies the other
missing components, but the doubling effect comes from SYS$DISK being
a search list.

> > $ 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.
>
> OK, but I had two ;1 in the same directory.

That's the same effect, but with a different scenario. To produce an
exhaustive set of examples would be quite exhausting. (BTW, add /FILE
to your DIRECTORY commands just to be sure of what's going on.)

Trust me: Move on.

AEF

On Nov 16, 10:32=A0pm, AEF <spamsink2...@yahoo.com> wrote:
> On Nov 16, 5:33 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
>
> undress to reply) wrote:
> > In article
> > <a22d5e50-e880-425b-9c93-252e27fa4...@g23g2000yqh.googlegroups.com>, AE=
F
>
> > <spamsink2...@yahoo.com> writes:
> > > 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 might be assumed from the example above, but I first saw the
> > command with logicals which were defined as DISK:[DIR], so each logical
> > name was a full path.
>
> It does this if *any* field (including name, type, and version number)
> is left blank or contains an asterisk. It also supplies the other
> missing components, but the doubling effect comes from SYS$DISK being
> a search list.
>
>
>
> > > $ DIRECTORY GETTYSBURG:SPEECH.TXT;*
>
> > > Directory DISK1:[JONES.HISTORY]
>
> > > SPEECH.TXT;2 =A0 =A0 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.
>
> > OK, but I had two ;1 in the same directory.
>
> That's the same effect, but with a different scenario. To produce an
> exhaustive set of examples would be quite exhausting. (BTW, add /FILE
> to your DIRECTORY commands just to be sure of what's going on.)
>
> Trust me: Move on.
>
> AEF

Sorry, the example you quoted is not this effect, as you said. But the
effect *is* mentioned in the last part of the section:

[begin quote]

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

[end quote]

The actual output is not provided. I suggest running the above
commands with /FILE added. You will then see the same effect.

As before:

Take note and move on.

AEF