🚀 go-pugleaf

In article <1990Nov1.142426.19559@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes:
>>   From article <22926@grebyn.com>, by jmbj@grebyn.com (Jim Bittman):
>>   >    One question (to which I had no answer) was:  
>>   >    "Why wasn't the 128 byte command line limit fixed between DOS 
>>   >     versions 1.0 and 1.1?"

>The answer is really quite simple:  it would break existing programs.  The 
>design for the command line is really inflexible:  it's supposed to be 
>located at offset 128 in the PSP segment, and .COM programs are guaranteed to 
>load at offset 256 in the same segment. 

Horray! I wrote a reply to jmbj@grebyn.com stating this, and then noticed 
many followups *not* noticing this. The reasoning actually dates back to the
format of CP/M executable files, and that MS/DOS was really a CP/M clone, not
a *NIX clone like many people wish.

>Now, my opinion:  there's not much wrong with a 128 byte limit.  People rarely
>want to type lines that long (and rarely get them right when they do); it's only
>programs and shells that like to create such long command lines.  Let them
>figure out their own way to pass arguments to programs that can accept lots. 
>Response files work well, for example.

If you use 4DOS, an environment variable contains the (up to 255 character)
command line.

>As to the idea of the shell performing filename expansion:  what a bad design
>that is.  Programs should see what the user types, not what the
>shell transforms it into.

Although *NIX freaks will flame this, it is true, IMHO. How I hate to have to
quote things to keep the shell from parsing the line. As far as the saving
coding time and consistant user interface arguments go, you can always call
an OS function to constantly parse the command line if appropriate (the DEC
RT-11 system had such a call) -- even MKS toolkit does this with the GLOB
program.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply