[comp.org.decus] making VMS better... filelist specification generalization

btb@ncoast.UUCP (Brad Banko) (12/06/86)

It just occurred to me today that DEC could make VMS friendlier by simply
generalizing their filespec for a list of files, i.e.:

	filespec1,filespec2,...	including wildcards, etc.

to include "@filespec", where filepec would be the spec of a file that has
a list of filespecs one to a line:

	@filespec, where filespec contains:

		filespec1, filespec2, filespec3   (or!)

		filespec1
		filespec2
		... (possibly even @filespec...)

this would really make certain types of operations easy, since there already
exist ways to create such "@filespec" files from various commmands under
VMS, such as	directory/nohead/notail/output=filespec matchfilespec..., or

		search/window=0/output=filespec matchfilespec...

then, if you were looking to make a list of files, for example, that
contain occurences of one match pattern and another, not necessarily on
the same line, you could just do:

		search/window=0/output=filespec searchfilelist pattern1

		search/window=0/output=finaloutput @filespec pattern2

etc., etc.... am I missing something, does vms already support this
functionality in some way (I don't mean this particular example, but the
general idea...)  Otherwise, you have to write several mindless dcl com
files to read such filelist files...  

	What an elegant extension this would be to VMS!  Yes?


-- 
			Brad Banko
			...!decvax!cwruecmp!ncoast!btb
			Cleveland, Ohio

-- 
			Brad Banko
			...!decvax!cwruecmp!ncoast!btb
			Cleveland, Ohio

billw@navajo.STANFORD.EDU (William E. Westfield) (12/09/86)

In article <1784@ncoast.UUCP>, btb@ncoast.UUCP (Brad Banko) writes:
> It just occurred to me today that DEC could make VMS friendlier by simply
> generalizing their filespec for a list of files
> to include "@filespec", where filepec would be the spec of a file that has
> a list of filespecs one to a line:

But that would make VMS look more like tops20!
they would never do that!

BillW

chris@usc-oberon.USC.EDU (Christopher Ho) (12/11/86)

Note that VMS already has limited indirect file capability.  I can
create a file called T.COM with the following:
	/debug t,sys$library:cshare/option
and say:
	$ link@t
and the rest of the command line gets sucked in from that file.  Note
that there must be no space, otherwise VMS thinks the '@' is part of
the filespec.

btb@ncoast.UUCP (Brad Banko) (12/11/86)

@file in the generalization of a VMS filelist would be more like tops20?
is that good or bad?  it would be closer to some of the flexibility of
Unix... is compatibility or similarity between OS systems against the rules
at DEC?

-- 
			Brad Banko
			...!decvax!cwruecmp!ncoast!btb
			Cleveland, Ohio

dbb@aicchi.UUCP (Burch) (12/13/86)

In article <1784@ncoast.UUCP> btb@ncoast.UUCP (Brad Banko) writes:
>It just occurred to me today that DEC could make VMS friendlier by simply
>generalizing their filespec for a list of files, i.e.:
>
>	filespec1,filespec2,...	including wildcards, etc.
>
>to include "@filespec", where filepec would be the spec of a file that has
>a list of filespecs one to a line:
>
>	@filespec, where filespec contains:
>
>		filespec1, filespec2, filespec3   (or!)
>
>		filespec1
>		filespec2
>		... (possibly even @filespec...)

Hold it!  I Know that you can do this under RSX.  I remember having done this
under VMS.  It may be that I did it with an incompatibility mode image, but
I do remember it.

The RSX routines to do this are in PIPUTL.OLB on the RSX distributions, and
have been described in the Multi-Tasker some years back, although the best
documentation is the utility source kit.


-- 
-David B. (Ben) Burch
 Analysts International Corp.
 Chicago Branch (ihnp4!aicchi!dbb)

"Argue for your limitations, and they are yours"

btb@ncoast.UUCP (Brad Banko) (12/15/86)

Since posting the original question/suggestion, I have learned that
@filespec is acceptable to some commands, but the file format is not
compatible with the output of :

	dir/nohead/notail/output=file ...

or 	search/window=0/output=file ...

which each produce a list of filespecs, each on a separate line (i.e.,

		filspec1
		filespec2...

	which, as far as I know, is not compatible with the @filespec
that some commands already accept... what these commands expect is a
@file that has exactly what you would type yourself, e.g.,

	search @file, where file=

	searchfilespec1,searchfilespec2,... pattern list

	or:

	searchfilespec1, searchfilespec2,... -
	pattern list...

	The file indirection doesn't supplement the command parameter
list, it replaces it.  (sigh! DEC!)



-- 
			Brad Banko
			...!decvax!cwruecmp!ncoast!btb
			Cleveland, Ohio