Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!hagbard!sunic!news.funet.fi!hydra!poros!kankkune From: kankkune@cs.Helsinki.FI (Risto Kankkunen) Newsgroups: comp.os.msdos.programmer Subject: Re: Long command lines Message-ID: <7658@hydra.Helsinki.FI> Date: 25 Sep 90 14:10:27 GMT References: <2728@dataio.Data-IO.COM> <7214@hydra.Helsinki.FI> <1990Sep24.110816.9221@canterbury.ac.nz> Sender: news@cs.Helsinki.FI Organization: University of Helsinki, Department of Computer Science Lines: 91 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)