Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lynx.northeastern.edu!cschmidt
From: cschmidt@lynx.northeastern.edu
Newsgroups: comp.lang.c
Subject: Re: Appending environment variable to system calls
Message-ID: <memo.895702@lynx.northeastern.edu>
Date: 6 Apr 91 19:19:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 99

> I wish to be able to set an environment variable (the path to a file)
> and then to execute a program using the system() function in the
> following fashion [under DOS]:
>
>     char *s;
>     s=getenv("FOO");
>     system("FOO/FUBAR");

This brings to mind the following terrific idea.  The DOS environment
can be used to implement "logical names" in a manner similar to
logical names on VMS.  I have been doing this for years with great
success.

All my DOS programs allow you to use "logical names" in place of
actual directory names and file names.  To illustrate how this
technique works, suppose I were to define a symbol as follows:

        SET H=C:\TC\INCLUDE\*.H
    or
        SET I=C:\TC\INCLUDE\
    or
        SET TC=C:\TC\

I could then use my DOS File Manager program to access header files in
the directory C:\TC\INCLUDE\ by typing:

        FM H:
    or
        FM I:.H
    or
        FM TC:\INCLUDE\.H

The rule is that wherever a colon appears in a file specification, if
the token to the left of the colon is an environment symbol, then the
colon and the symbol are replaced by the translation.  It's basically
just a macro processor.  The colon can be followed by the remaining
portion of a complete path or file specification.  Alternatively, the
logical name itself might define a complete file specification.

Syntactically, the logical name is identical to the drive name portion
of a complete DOS file specification, except that logical names are
not limited to a single letter.  If the logical name is found in the
DOS environment, the logical name and the colon are replaced by the
translation; otherwise, the logical name and the colon remain in
place, so actual drive names are not affected.

Logical names can be defined in terms of other logical names.  Logical
name translation is repeated until no candidate logical name is found
in the resulting translation (signaled by the absence of a colon), or
until no translation is found in the DOS environment, or until the
maximum number of iterations is reached.  A maximum of eight
iterations avoids looping indefinitely in the case of circular
definitions.  Wherever translation produces consecutive backslashes,
one of the backslashes is deleted, which is helpful when referring to
nested directories.

Returning to the original problem, if you write a function named
"translate" or whatever that returns a pointer to a string containing
its input parameter with logical names translated, the solution to
your problem might look something like this:

        system (translate ("FOO:FUBAR"));

(In practice, I do not usually approve of functions that return
pointers to internal static strings, but that is another issue.  Also,
an application with a hard-coded logical name should probably test
whether that logical name is defined before trying to use it.)

As an additional advantage, this technique is portable to VMS and Unix
(I think).  I do know that Unix has environment variables, and I know
of no conflict that might result from using the colon this way in Unix
file specifications.  (Corrections on this point will be gratefully
received.)  Logical names seem much simpler to me that Unix "file
links", which are usually used to accomplish the same thing.  (Logical
names are more powerful in some respects than links, and vice versa.)

I think Microsoft should provide full support for logical names as
defined here, in both DOS and OS/2 and in their compiler runtime
libraries, and of course in their application products.  Microsoft
could then phase out the numerous, cumbersome, less powerful features
they added to DOS to accomplish the same thing.

Programmers and users have always been dissatisfied with the methods
DOS provides for programs to find their data files.  The sheer number
of methods that have appeared in successive versions of DOS indicates
the failure of any one method to provide an adequate solution.  The
logical name method is both simpler and more powerful than all other
methods combined.  If all DOS programs supported logical names, the
DOS commands APPEND, ASSIGN, JOIN, and SUBST would never be needed.
Users would be provided with a single, versatile method that would
work across application, and across platform as well.

In the meantime, you and your customers will benefit if you add
logical name support to all your DOS programs.  I would like to know
what you think about that.  It has worked wonderfully well in the many
DOS applications I have written.

Christopher Schmidt
cschmidt@lynx.northeastern.edu