🚀 go-pugleaf

In article <1990Sep24.110816.9221@canterbury.ac.nz> phys169@canterbury.ac.nz writes:
>In article <7214@hydra.Helsinki.FI>, kankkune@cs.Helsinki.FI (Risto Kankkunen) writes:
>> In article <2728@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
>>>A parameter starting with @ is taken to be a 'response file'. The response
>>>file is read in and inserted into the command line replacing the @filename...
>>
>> I don't see this as the final solution, because it is a purely
>> syntactic, command line convention.
>> 
>Quite right, it shouldn't be a "final solution", but it isn't all that bad for
>the moment, either.

The response file method is quite good and flexible, I agree. But I'd
like to see some effort put, for example, on the environment segment
method, so we could solve this long command line problem for good.
Otherwise, we end up having lots of unnecessary conventions that every
programmer must support for backward compatibility.

So let's first see, if the environment method can be implemented (Or
does someone see any problems with this methods, or know a better way
to go?). If it can't be done without a new system call, then we must
maybe use response files etc. while waiting for Microsoft to react (and
that might take a long time...).

>Ultimately, it looks like DOS
>will want to use the special area after the environment. I believe command
>interpreters could set this up now, even without waiting for DOS to do it, but
>with some large degree of mess (loading a program in "by hand", and all that).

I don't think it requires any funky stuff to get working. And you don't
have to load the program by hand, because there is this "undocumented"
call to do it. And this is the call by which DOS DEBUG, and I think some
other debuggers, load programs to debug. So it isn't some obscure
internal function that might disappear in the next release of DOS.

>What is important is what goes in on the application program side of things.
>
>> And because the command line would be broken up into arguments, the
>> program wouldn't have to parse it (and try to guess what command shell
>> the user has to do it right).
>
>But the parsing is going to make assumptions, e.g. some people consider that: 
>PRINT file1,file2,file3 file4 has 2 parameters after the "PRINT" (one is the
>concatenation of files 1,2 & 3, which would be printed as one file, then file4;
>others would expect 4 separate parameters. Some programs treat what others
>consider to be a delimiter as special, and need to know it).

I think most of the programs are written in high level languages, like
C and Pascal. In these languages you don't access the command line
directly. Instead, the startup code parses it and separates to
parameters. You access these via the argv array in C and ParamStr in
TP.

So, every program written in high level language parses the command
lines, and makes lots of unnecessary assumptions, before the program
gets them. If the command line is passed in parameters, it is the shell,
and ultimately the user that makes the assumptions and decisions.

For example, in your PRINT example above, you could quote, or some
other way indicate, that the comma separated list is one parameter, if
your shell normally splits parameters at commas. However, currently the
startup code always parses the line and you couldn't even write PRINT
program like above, if your compiler treats commas as parameter
delimiters (ok, you can write your own startup code, but that's not the
point).

>Hopefully, the start of the un-processed command line would still be there, in 
>the PSP, but somebody (everybody?) has to work out what you can expect a shell 
>to do and not do first, and allow time for program writers to adjust to that.At
>the moment, the majority of programs for PC's at least are written under the
>assumption that they will be called from COMMAND.COM, not some "foreign" shell.

The unprocessed line would of course be there, so old programs won't
stop working. As for new programs, I don't see any problems. In normal
high level languages any modifications shouldn't be needed. The only
difference would be that they now could receive more and longer
parameters.

>I realise the information content is dropping a bit as personal opinions take 
>over, so feel free to e-mail me with further comments, flames, whatever.

No need to flame anybody. I prefer to post, so that we can discuss this
together and hear what everyone thinks about this issue. I thought this
topic would draw much more opinions and I hoped to get some technical
help from you gurus of DOS innards. Maybe it is just that everyone is
happy with their DOS... 8-}

I'm sorry, but it seems I can't write short follow-ups...
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    rkankkunen@finuh         (Bitnet)
 University of Helsinki, Finland   ..!mcvax!uhecs!kankkune   (UUCP)