I've made a few corrections to what Patrick wrote here. My intent was
certainly not to belittle what he provided, but merely to illustrate how
a project of this nature might not be as simple or as straightforward as
it initially appears to be.
Patrick Spinler wrote:
>
> Some corrections & additions:
>
[some text deleted]
> Some explaination should be given of VMS paths and logical names.
> Here's an off the cuff effort below:
>
> -- Pat
>
> VMS File Path Syntax
> ====================
>
> Unlike in Unix, a file path in VMS consists of several distinct
> componants which may be distinguished from each other by unique file
> path seperator characters. A useful characteristic to keep in mind is
> that if part of the path stays the same as the current 'file path
> context', it need not be respecified.
>
> For example, a complete file path on VMS might look something like the
> following:
>
> NODENAME"username password"::DISK:[topdir.second.third]filename.ext;REV
>
> If instead you wanted to refer to something on the same node, you could
> use the following:
>
> DISK:[topdir.second.third]filename.ext;REV
>
> If you wanted to refer to a disk with the same name on a different node
> as the same user you are currently logged in as, the following might work:
>
> NODENAME::[topdir.second.third]filename.ext;REV
Correction: this will refer to whatever disk is the default disk of the
remote account you are referencing. It bears no relation to the name of
the disk on the local node.
>
> If you just wanted to look in a subdirectory of your current directory,
> use this:
>
> [.subdir]filename.ext;REV
>
> A couple of useful rules to remember.
>
> *) Leave off the revision number (REV - see file version numbering below
> for a complete explaination) and it will default to the latest revision
>
> *) Revision numbers (REV) can be a negative offset, which means -N
> revisions from the current one. E.g. filename.ext;-3 means the 4th most
> recent revision.
Special case: Version -0 refers to the earliest version.
>
> *) The dash "-" used in a directory name means the parent directory.
> Eg: [.-.-] is two directories above your current directory
Correction: E.g.: [--] is two ...
>
> *) Ellipses used as the last part of a directory means "and all
> subdirectories". Eg: [topdir...]*.* means all files in [topdir] and
> everything below it
Directories can contain wildcards. For example, [topdir.*.dir3] refers
to every subdirectory of topdir that also has a subdirectory called
dir3.
>
> Logical Names and VMS File Paths
> ================================
>
> VMS has a facility similar in some ways to the Unix concept of
> environment variables, called Logical Names. (VMS Has another, very
> superficially similar facility called symbols, but we'll cover that later)
Actually, symbols are far closer to environment variables. Unix has no
equivalent (or close equivalent) to logical names. It should also be
noted that symbols can perform the same function as the Unix alias
command.
>
> The nice thing about logical names is that they can be transparently
> used to substitute for part of a file path. You don't need to use any
> special syntax, the filesystem handling code in VMS (RMS) transparently
> performs logical name substitution for you, with no extra effort.
>
> The only limitation is that a logical name must always appear at the
> _start_ of a path, and is terminated in a path by a colon. Here's how
> it can work.
Neither of these statements is true. For example:
node::some_logical:[dir.dir]
will work just fine yet the logical is not at the start of the path.
A logical name need not have a colon. One is only needed if there is
additional data beyond the logical name. For example: type sys$sylogin
will type out whatever file that logical name points to but no colon is
to be found.
>
> A logical name can substitute for 3 distinct subsets of a VMS file path:
Hmm, I suppose that depends on how much of the flexibility of logicals
and filename parsing you want to describe. For example, try the
following:
define xxx sys$sysdevice:filename
write sys$output f$parse("[000000].e","xxx")
This example, plus what you are showing, indicate that a logical can be
used to explicitly specify part or all of a filename, or it can be used
to fill in any missing part of a filename.
>
> 1) The node and or disk name:
>
> For example, if you have the path:
> NODENAME"username password"::DISK:[topdir.second.third]
If I were writing a book about this I would mention DECnet proxies and
then mention how an explicit username, or username and password, can be
used when a proxy does not exist (or where multiple proxies exist). All
examples after this point could then be given with just node references.
> You could do this:
> $ define remote_machine "NODENAME""username password"""
> $ dir remote_machine::DISK:[topdir.second.third]
A logical name that is going to reference a node name must include the
double colon, i.e. define remote_machine "NODENAME""username
password"""::
>
> Note the double quotation marks, that's to pass the special character
> though the VMS shell, DCL, similar to using a backslash on Unix.
A double quote is used to place a quote inside a string (i.e. "" instead
of \"). It is not used for any other special character. In fact, all
of the characters I can think of that must be escaped in Unix with the \
can be included literally in VMS.
>
> or this:
> $ define remote_disk "NODENAME""username password"::DISK:"
> $ dir remote_disk:[topdir.second.third]
>
> or even use one logical inside another, like this:
> $ define remote_machine "NODENAME""username password"""
> $ define remote_disk "remote_machine::DISK:"
> $ dir remote_disk:[topdir.second.third]
>
> 2) For the (optional) node and disk name, and _part of_ the directory
> path. This is refferred to as a "rooted" logical, and can be used
> identically to a DISK specification normally.
>
> For our example above, we could do this:
> $ define remote_machine "NODENAME""username password"""
> $ define remote_disk "remote_machine::DISK:"
> $ define/translation=concealed PSUEDODISK remote_disk:[topdir.]
> $ dir PSUEDODISK:[second.third]
>
> There are two limitations to be aware of for rooted logical names.
> a) First, the directory specification part must end in a period,
> followed by a right square bracket. E.g. disk:[path1.path2.], not
> disk:[path1.path2]
> b) Second, unlike other logical names, there can be only one rooted
> logical name used in a path, a rooted logical cannot translate into
> another rooted logical.
>
> 3) Finally, a logical name can refer to a fully qualified directory
> and/or a full directory and filename.
>
> For example
> $ define remote_machine "NODENAME""username password"""
> $ define remote_disk "remote_machine::DISK:"
> $ define remote_path remote_disk:[topdir.second.third]
> $ dir remote_path:
>
> or
> $ define remote_machine "NODENAME""username password"""
> $ define remote_disk "remote_machine::DISK:"
> $ define remote_path remote_disk:[topdir.second.third]
> $ define remote_file remote_path:filename.ext
> $ dir remote_file
>
> There are lots of other wierd and wonderful things you can do with
> logical names, such as putting a list of files or directories into one,
> using them to refer to devices or batch queues, or messing around with
> the directory of tables containing logical names, etc, but those topics
> are for a later, more advanced, section.
>
> Specifying a new command at the shell (DCL) prompt
> ==================================================
>
> In Unix, in order to be able to execute a command from a shell, one
> simply inputs the command as the first item in a command specifier. The
> Unix shell then searches first it's own internal command tables, then
> for a file with a matching name on a list of directories specified in
> the PATH environment variable.
>
> Unlike Unix, with the advent of revision 6.2 of VMS, there are at least
> five methods to run a command from the faithful DCL dollar sign prompt.
>
> 1) First, like Unix, the DCL shell has a number of built in commands.
> Unlike unix, however this list of built in commands can be dynamically
> extended using a special language, called appropriately enough, Command
> files, or CLD files.
Command Language Definition files, actually. Command files are, I
believe, how most people refer to the files that end in .COM.
>
> This feature on VMS is especially neat, since a command with a properly
> specified CLD file can perform almost it's entire option processing
> without ever invoking the target program, amoung other neat stuff.
Something that should always be mentioned to Unix people when talking
about this, IMHO, is the following:
Because DCL (the command shell) validates the arguments before executing
the program, rather than requiring each program to do its own
validation, VMS provides extremely consistent syntax among its commands
as well as consistent error messages related to command parsing.
>
> Individual CLD files can be loaded into your DCL interpeter using the
> 'set command' command. Type 'help set command' to see how to use this
>
> 2) The simplest way to invoke a program is to use the "run" command
> under VMS. This is rarely used from the command line, however, since
> there is no mechanism to specify parameters to the program run, all the
> parameters apply to the RUN command itself.
>
> It is heavily used, however, to run the VMS equivilent of Unix daemons,
> called detached processes. Type 'help run/detached' to get more
> information on doing this.
>
> To run a specific program using this, simply type 'run program.exe'
>
> 3) An undocumented but widely used mechanism to run a program that isn't
> in DCL's command tables is the 'MCR' command. Unlike 'RUN', 'MCR' does
> allow command parameters. It's used like this:
>
> $ mcr disk:[dir.subdir]program.exe param1 param2 ...
>
> Note that you will have to specify at least a partial path to MCR.
> Unlike other, documented, VMS commands, it does not use the current
> default directory (pwd on Unix).
It does have a default directory. It's just that it defaults to
SYS$SYSTEM rather than the process's current default. This is
consistent with what MCR was originally designed for (i.e. calling RSX
programs into execution).
Also MCR is, in fact, documented. It has been in VMS since V1 and has
always been documented. I'll grant you that its documentation has
shrunk over the years as the need for RSX compatibility has
disappeared. However, it is still in the Master Index and is still
documented as the equivalent of RUN SYS$SYSTEM: with the added ability
to include command arguments on the command line.
>
> 4) If you want to run a command without using any of the tricks above,
> you can use the VMS symbol table to specify commands in a "shorthand"
> manner, like this:
>
> If you have a program like this:
> disk:[dir1.dir2]someprogram.exe
> or a script like this:
> disk:[dir1.dir2]somescript.com
>
> You can make a DCL 'shorthand' command for these two things like this:
>
> $ someprogram :== $disk:[dir1.dir2]someprogram
> $ somescript :== @disk:[dir1.dir2]somescript
>
> There are a couple of caveats to be aware of:
>
> a) Use "$" for compiled code (EXE's), and "@" for DCL scripts (COM's)
> b) Unless you specify the file extension, it's assumed to be EXE for
> executables, and COM for scripts.
>
> You can put a list of these command definitions into your LOGIN.COM file
> to have them handy for use.
>
> 5) Finally, as of VMS 6.2, VMS has implementated a Unix like PATH
> specifier.
>
> If you type a command at a VMS prompt, DCL will first search it's
> internal command table, then it's 'shorthand' commands for a matching
> name. If it does not find any, it will then search the list of
> directories contained in the special logical named DCL$PATH for an
> executable or script with a matching filename.
>
> So, for example, you could do the following:
>
> $ define dcl$path disk:[gnu_stuff.bin], disk:[perl.5_6_1], -
> disk:[scripts]
>
> Then, if you typed 'perl' at a dcl prompt, and you had a 'perl.exe' in
> disk:[perl.5_6_1], it would find and execute that program.
>
Mark Berryman
