ral@pyuxqq.UUCP (R A Levenberg) (06/02/85)
DOS seems to behave very differently from the UNIX shell when it comes to parsing command line arguments. For example, the UNIX shell will parse this command line sed 's/x/ /g' <file into 2 arguments, sed s/x/ /g The sed command never knows that quotes were used to define the argument. The same does not seem to be true in DOS, where I think the above command would produce these arguments sed 's/x/ /g' How, then, does one pass an argument containing delimiters such as blanks to a DOS command (especially a UNIX command ported to a PC)? A related question is the evalution of, say, *.c, on a command line. DOS (actually command.com) will tell the invoked program its argument is "*.c", whereas the UNIX shell will tell the invoked program its arguments are, say, main.c, foo.c and bar.c. Does this mean that DOS programs use those SYSINT system calls themselves to get first matching file name and next matching file name whenever an argument contains wild card characters? Ron Levenberg, Bell Communications Research 3 Corporate Place Room 2c-315 Piscataway, NJ 08854 (201) 981-6178 ..!allegra!pyuxqq!ral
nather@utastro.UUCP (Ed Nather) (06/05/85)
> DOS seems to behave very differently from the UNIX shell > when it comes to parsing command line arguments. True. It separates at white space only (spaces or tabs). > How, then, does one pass an argument containing delimiters such > as blanks to a DOS command (especially a UNIX command ported to a PC)? A few brave people have added quoted strings and filename expansion to the setup program _main generated by various compilers, but I know of no uniform solution. MS-DOS needs a better shell. If anyone has hacked command.com to include these things, I hope they will post it to the net. > Does this mean that DOS programs > use those SYSINT system calls themselves to get first matching file name > and next matching file name whenever an argument contains wild card > characters? > Ron Levenberg, Bell Communications Research Sadly, yes. Of course, DOS only cost $60 list, and Unix cost us $600 ... :-) -- Ed Nather Astronony Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather%utastro.UTEXAS@ut-sally.ARPA
knutson@ut-ngp.UUCP (Jim Knutson) (06/05/85)
If you want to port UNIX commands to a DOS environment, I suggest
you start with modifying _main for whichever C compiler you are
using and make it parse arguments like the shell would. I'm getting
ready to do that with mine after trying to port things like grep
and finding there was no way I could put a blank in the search string.
Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: (512) 471-3241dan@digi-g.UUCP (Dan Messinger) (06/06/85)
In article <715@pyuxqq.UUCP> ral@pyuxqq.UUCP (R A Levenberg) writes: >the UNIX shell will parse this command line > sed 's/x/ /g' <file >into 2 arguments, > sed > s/x/ /g >The sed command never knows that quotes were used to define the >argument. The same does not seem to be true in DOS, where I think >the above command would produce these arguments > sed > 's/x/ > /g' >How, then, does one pass an argument containing delimiters such >as blanks to a DOS command (especially a UNIX command ported to a PC)? DOS does not parse parameters at all. It is up to the application to do it. It is code that is added by the C compiler that is doing the parsing before calling main() of the application. So it is up to the C compiler to recognize quotes. Your above example works fine under DOS if you use the MS version 3 C with "...". It doesn't recognize '...'. Also, "s will prevent DOS from acting on <, > and |. >A related question is the evalution of, say, *.c, on a command line. >DOS (actually command.com) will tell the invoked program its argument >is "*.c", whereas the UNIX shell will tell the invoked program its arguments >are, say, main.c, foo.c and bar.c. Does this mean that DOS programs >use those SYSINT system calls themselves to get first matching file name >and next matching file name whenever an argument contains wild card >characters? Afraid so. I heard a rumor once that the MS ver 3 C would expand match characters. I've tried it, and it doesn't. Dan Messinger ihnp4!umn-cs!digi-g!dan
rde@ukc.UUCP (R.D.Eager) (06/07/85)
Both cases mentioned (processing of quotes and expansion of wildcards)
are NOT done by the DOS command interpreter. It simply passes the entire
command line (after the command name) to the program being invoked.
This is reasonable when you realise that this isn't UNIX, after all; DOS
has some UNIX-like features but it doesn't claim to BE UNIX!
Porting of useful UNIX programs is another story. Any half decent C
runtime system should surely present arguments to a program in UNIX
form, at least as an option. Surely it should handle quotes and expand
wildcards too; then porting of programs is much simplified.
This approach was used on a software tools kit (Lawrence Livermore Labs
I think), where all the parameter munging was done OUTSIDE the program
but INSIDE the runtime system.
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589rsellens@watdcsu.UUCP (Rick Sellens - Mech. Eng.) (06/08/85)
It may be an ugly solution, but the exact command tail is available in the program segment prefix created for the command. (I think it is at offset 80h, but check the manual.) You can write your code to pick it up raw and parse it in any way you want. What you get is simply the complete string of characters that followed the command name. This includes any white space, etc. Rick Sellens UUCP: watmath!watdcsu!rsellens CSNET: rsellens%watdcsu@waterloo.csnet ARPA: rsellens%watdcsu%waterloo.csnet@csnet-relay.arpa
kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (06/09/85)
In reference to expanding wildcards, this is another area where the new Microsoft C compiler excels. It is possible to have your C programs do wildcard expansion of filenames. I don't know how it handles quoting, but I'll go home and check. Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@ucsf-cgl.ARPA If your mailer has trouble with the above Arpanet address, try: @berkeley.arpa:kneller@ucsf-cgl.arpa
kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (06/09/85)
In article <646@digi-g.UUCP> dan@digi-g.UUCP (dan) writes: >In article <715@pyuxqq.UUCP> ral@pyuxqq.UUCP (R A Levenberg) writes: >it. It is code that is added by the C compiler that is doing the parsing >before calling main() of the application. So it is up to the C compiler >to recognize quotes. Your above example works fine under DOS if you use >the MS version 3 C with "...". It doesn't recognize '...'. Also, "s will >prevent DOS from acting on <, > and |. > >>A related question is the evalution of, say, *.c, on a command line. >>DOS (actually command.com) will tell the invoked program its argument >>is "*.c", whereas the UNIX shell will tell the invoked program its arguments >>are, say, main.c, foo.c and bar.c. Does this mean that DOS programs >>use those SYSINT system calls themselves to get first matching file name >>and next matching file name whenever an argument contains wild card >>characters? > >Afraid so. I heard a rumor once that the MS ver 3 C would expand match >characters. I've tried it, and it doesn't. > >Dan Messinger >ihnp4!umn-cs!digi-g!dan Sorry to differ with you Dan, but MSC version 3.0 DOES do wildcard matching but you have to link in a 'varargs.obj' file that comes with the compiler. Then *.c expands to all .c files in your current directory. Since the expansion is done after the commandline is passed to your program, this is also a way to get around the 127(?) character command line limit. As is also mentioned above, MSC also correctly handles a command line argument like "a b c". Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@ucsf-cgl.ARPA If your mailer has trouble with the above Arpanet address, try: @berkeley.arpa:kneller@ucsf-cgl.arpa
kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (06/10/85)
Sorry about the previous posting about linking in a 'varargs.obj' file for getting wild card expansion under MSC version 3.0 The file name should be '?setargs.obj' where '?' is one of 'S', 'M', or 'L' (sometimes I really wish for a linear architecture) Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@ucsf-cgl.ARPA If your mailer has trouble with the above Arpanet address, try: @berkeley.arpa:kneller@ucsf-cgl.arpa
cramer@kontron.UUCP (Clayton Cramer) (06/10/85)
> >A related question is the evalution of, say, *.c, on a command line. > >DOS (actually command.com) will tell the invoked program its argument > >is "*.c", whereas the UNIX shell will tell the invoked program its arguments > >are, say, main.c, foo.c and bar.c. Does this mean that DOS programs > >use those SYSINT system calls themselves to get first matching file name > >and next matching file name whenever an argument contains wild card > >characters? > > Afraid so. I heard a rumor once that the MS ver 3 C would expand match > characters. I've tried it, and it doesn't. > > Dan Messinger > ihnp4!umn-cs!digi-g!dan MS ver 3.0 C does expand match characters, but you have to link your program with SSETARGV.OBJ (or the medium or large equivalents) for the wild card arguments to expand. It does work; I wrote a program to do verified erases (query user on each file, asking if he wants to delete this file) using this facility.