Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!virtue!canterbury.ac.nz!phys169 From: phys169@canterbury.ac.nz Newsgroups: comp.os.msdos.programmer Subject: Re: Long command lines Message-ID: <1990Sep20.102811.9190@canterbury.ac.nz> Date: 20 Sep 90 00:25:10 GMT References: <26da5df5@ralf> <7192@hydra.Helsinki.FI> Organization: University of Canterbury Lines: 82 In article <7192@hydra.Helsinki.FI>, kankkune@cs.Helsinki.FI (Risto Kankkunen) writes: > In article <26da5df5@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: >>In article , bright@dataio.UUCP wrote: >>}[passing long command lines in an env var] >>}What name do they use for the environment variable? Is there any sort >>}of defacto standard for this? ...If there is no commonly used environment >>}variable, how about defining one, I propose "CMDLINE". There can be a problem using the environment to store long command lines with conventional DOS: the environment space is small by default, and if you increase it in config.sys you have to choose a number large enough for any long command line you might need in the future, and this wastes space each time a program is nested. >>}What if both the environment variable >>}and a command line exist, does the environment variable come 'before' >>}or 'after' the command line? My software generally uses the conventions: (a) if there is an environment variable with the same name as the program, it inserts that string *before* the given command line in the PSP, assuming it contains options (which traditionally go before other parameters, but in fact I allow them anywhere). (b) if the command line (or, for that matter, the envirnoment string mentioned in (a) above), contains " @" followed by a filename, the contents of that filename are inserted in the command line (where the "@" and filename was). Althought this potentially allows for *very* long command lines (I'm used to DG RDOS & B.Basic with kilobytes worth of command parameters!), all my programs at the moment are limited to a total of 255 bytes, still, it's an easy way to get around the fact that people may use the software from any version of DOS (2+) and any environment allocation, and any command interpreter. (c) I'm happy to look for an environment variable called CMDLINE; I suggest its contents should go *after* whatever is in the command line already. > > An environment variable is simple to use, but I think it would be > cleaner to place the command line arguments after all the variables and > the terminating double null in C/Unix-fashion. After all, there is > already the program name (=argv[0]) there and the word preceeding it > contains 1, so it seems to be argc... (d) I'd like to see such a method become a standard, but this would really need replacing COMMAND.COM. The idea of placing them after the program name in the environemt would be good, so long as enough people (and alternative command interpreters) get together and agree on it. From DOS 2 onwards, it is possible for each program called to get the environment space it actually needs, but so far the memory allocation systems seems a bit poor, to say the least. >>The 4DOS COMMAND.COM replacement uses CMDLINE to store the full command line.. I haven't played much with 4DOS, but this underlines up the question of what we (the programming community, I guess), could do to set standards for command interpreters. I suggest that, in addition to programs using (a) to (c) above, and checking for a command interpreter doing (d), we define a few extra punctuation features for command interpreters while we're at it, so everyone can plan for them. So I suggest that command interpreters... (e) expand any [@filename] to include the contents of the file in the command. Notice the [ and ] around it; it would pass any plain "@" unchanged, for compatibility with anything that presently wants a "@" in the command line. Possibly %@filename% would be more consistent, but I prefer to see [ and ] because it is easier to spot mistakes than with %, and is better for nesting, and is similar to DG's AOS operating system - not that I'm going out of my way to copy others, but if someone's got a standard already, why invent a new one? (f) expand any [@filename number] to include the given line number from the given file, as above. (g) expand any [!command] by executing the command after the [! and placing whatever it writes to the standard output into the new command line's text. This is pretty much compatible with DG AOS/VS. (h) expand [?prompt] by asking the user for input. (i) define a "command continuation" character, e.g. ",", so command lines can carry on over one line of text, as per decent operating systems. (j) improve the piping facilities a little, e.g. a tee facility and perhaps a special highly-buffered device driver for temporary files, and ">>", etc. > Does anyone know if DOS 5.0 will set any standards in this area? I don't know about MSDOS 5, but DRDOS 5 allows @filename in most of its own utilities, (in the same way that my utilities do, it seems). It also allows /h for help (I would have liked /?, but at least it's something). Mark Aitchison, Physics, University of Canterbury, New Zealand.