Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!wind!naughton
From: naughton%wind@Sun.COM (Patrick Naughton)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Unix-like global expansion in DOS
Summary: The command line is too short.
Keywords: MS-DOS commandline length
Message-ID: <76192@sun.uucp>
Date: 4 Nov 88 07:45:16 GMT
References: <215@lcuxa.UUCP>
Sender: news@sun.uucp
Reply-To: naughton@sun.com (Patrick J. Naughton)
Organization: Sun Microsystems, Mountain View, CA
Lines: 37


I like the idea of having unix shell style wildcard expansion, but
having it be a C client function which has to be called before argv[]
processing kind of limits its usefulness.  The solution I would like to
see would be a COMMAND.COM shell enhancement (replacement?) which
handled the usual stuff like file completion, history substitution, AND
wildcard expansion.  This way the client program/command such as masm or
link (which always has long command lines under Unix) would already have
the correct arg[cv] values on startup.  This also has the advantage of
having only one copy of argexp() lying around rather than one copy per
client. 

This is a small matter of programming and I would certainly have already
done it if it were not for the point of this posting: The DOS command
line (last time I checked) had an upper limit of 128 characters.  Thus
any wildcard expansion which expanded out to more than 128 characters
would fail.  Does anyone know if this is hardwired, or where the hack
would have to go in to change it? I am guessing that it is because old
".COM" files put argv[] in the PSP which is only 256 bytes long.  It
seems that for an ".EXE" file, the process loader or the offset fixup-er
could allocate some space for the arg list no matter how long and point
argv[] at it.

This shortcoming of DOS/COMMAND.COM causes standard Unix Makefiles to be
useless since most link lines get to be several hundred characters, if
you have any reasonable number of libraries or object files.  DOS has
the @file convention for reading the args for commands out of, but it
makes Makefile management a nightmare and portability to Unix a moot
point.

Any comments or suggestions?

-Patrick
    ______________________________________________________________________
    Patrick J. Naughton				    ARPA: naughton@Sun.COM
    Window Systems Group			    UUCP: ...!sun!naughton
    Sun Microsystems, Inc.			    AT&T: (415) 336 - 1080