gahooten@titan (Gregory A. Hooten) (09/19/89)
In Unix, it is the shell that interprets the character *, what in DOS will do the same thing? Is it left to the Command.com, or is it left to each utility to do on its own? Thanks Greg Hooten GAHOOTEN@ames.arc.nasa.gov
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/19/89)
In article <32164@ames.arc.nasa.gov>, gahooten@titan (Gregory A. Hooten) writes: >In Unix, it is the shell that interprets the character *, what in >DOS will do the same thing? Is it left to the Command.com, or is it >left to each utility to do on its own? Each program has to do it on its own. This is actually much worse than COMMAND.COM doing it for you, because then you have differing interpretations of things like "*89.*" (does it mean "*.*", like COMMAND.COM thinks it does, or "any file with `89' in the name", like some other utilities do?), plus the bother of having to code the wildcard handling into programs that you write. On the plus side, it probably makes filename parsing a bit easier for the programmer, because they don't have to be able to parse a list of filenames the same way a Unix program does. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832 ?
rdas@hatter.Tops.Sun.COM (Robin Das) (09/20/89)
In article <32164@ames.arc.nasa.gov> gahooten@titan (Gregory A. Hooten) writes: >In Unix, it is the shell that interprets the character *, what in >DOS will do the same thing? COMMAND.COM does the * and ? processing in DOS. If you want a program to do the same type of thing, the program must include the smarts.
johnl@esegue.segue.boston.ma.us (John R. Levine) (09/20/89)
In article <635.25170D1F@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >In article <32164@ames.arc.nasa.gov>, gahooten@titan (Gregory A. Hooten) writes: > >In Unix, it is the shell that interprets the character *, what in > >DOS will do the same thing? ... > >Each program has to do it on its own. This is actually much worse >than COMMAND.COM doing it for you, because then you have differing >interpretations of things like "*89.*" (does it mean "*.*", like >COMMAND.COM thinks it does, or "any file with `89' in the name", >like some other utilities do?), ... It's not quite that bad. DOS has a system calls that take a wild card name and return the actual file names that match the pattern. The command processor expands wild cards that way, and most other programs that expand wild cards use the same calls and so they get results that are consistent. Unfortunately, DOS's idea of star matching is pretty poor. Some programs reimplement star matching themselves, usually to make it more like the way Unix does it, which is certainly better but since it's inconsistent with everything else it's confusing. Also, since DOS file names are more complicated that Unix names, a fully general star expander is very hard to write. I've never seen one that could handle *:foo and look for foo on every drive. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 johnl@esegue.segue.boston.ma.us, {ima|lotus}!esegue!johnl, Levine@YALE.edu Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
djm@castle.ed.ac.uk (D Murphy) (09/20/89)
In article <635.25170D1F@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >In article <32164@ames.arc.nasa.gov>, gahooten@titan (Gregory A. Hooten) writes: > >In Unix, it is the shell that interprets the character *, what in > >DOS will do the same thing? Is it left to the Command.com, or is it > >left to each utility to do on its own? > >Each program has to do it on its own. This is actually much worse >than COMMAND.COM doing it for you, because then you have differing >interpretations of things like "*89.*" (does it mean "*.*", like >COMMAND.COM thinks it does, or "any file with `89' in the name", >like some other utilities do?), plus the bother of having to code the >wildcard handling into programs that you write. >Marc Unangst Yes, each program has to contain wildcard handling routines, BUT DOS does it for you. You use the DOS functions 4Eh and 4Fh. 4Eh is `Find First File', and you pass as argument in DS:DX an ASCIIZ string containing the pathname you want to match. Any *'s are expanded to fill remaining space with ? characters (which is why an attempt to copy *.TXT with no matches gives the message ????????.TXT file not found). Anyway, the matched filename is placed at offset 1Eh from the disk transfer address (default PSP:80h, or you can set it with DOS function 1Eh if you want your own) and ASCIIZed. A subsequent call to 4Fh will either find the next matching file (you MUST NOT alter the DTA or this won't work) or return 18 in AX meaning there were no further matches. I don't think DOS will allow *89.* - it will allow 89*.*, which is expanded to 89??????.??? since the wildcard handling is somewhat primitive. The above does not work for DOS 1.0, it certainly works for 3.2 and maybe for 2.0, but I'm not sure. Murff.....
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (09/20/89)
In article <32164@ames.arc.nasa.gov> gahooten@titan (Gregory A. Hooten) writes:
$In Unix, it is the shell that interprets the character *, what in
$DOS will do the same thing? Is it left to the Command.com, or is it
$left to each utility to do on its own?
It's a mishmash. Some interpretation of *.* is done for you by DOS
(the part that lies above the BIOS but below the COMMAND.COM hierarchically).
For example, when you do a DIR *.*, COMMAND passes the *.* to the DOS
"Find first" (and, indirectly, "find next") routine which then takes care of
it.
On the other hand, if you try to rename or delete a group of files,
this is not done by DOS; DOS requires a single file name for this. COMMAND
(or any program you write) has to, in this case, translate *.* into a
series of filenames (this is done with the find first/find next calls).
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
**********************************************************************
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
"VM is like an orgasm: the less you have to fake, the better." - S.C.craigb@hp-sdd.hp.com (Craig Bosworth) (09/20/89)
In article <667@suntops.Tops.Sun.COM> rdas@hatter.tops.sun.com (Robin Das) writes: >In article <32164@ames.arc.nasa.gov> gahooten@titan (Gregory A. Hooten) writes: >>In Unix, it is the shell that interprets the character *, what in >>DOS will do the same thing? > >COMMAND.COM does the * and ? processing in DOS. If you want a program to >do the same type of thing, the program must include the smarts. DOS functions 4Eh and 4Fh, FINDFIRST and FINDNEXT search for files based on a wildcarded path name. I *imagine* COMMAND.COM uses these functions. Not wanting to "include the smarts" myself, I have used them. I have no idea how they rate performance- or bug-wise, but I've never had any prob- lems with them. BOS -- Craig Bosworth (619) 592-8609 16399 West Bernardo Drive Hewlett-Packard, San Diego Division San Diego, CA 92127-1899 UUCP : {hplabs|nosc|hpfcla|ucsd}!hp-sdd!craigb Internet : craigb%hp-sdd@hp-sde.sde.hp.com (or @nosc.mil, @ucsd.edu)
don@trsvax.UUCP (09/21/89)
>>In Unix, it is the shell that interprets the character *, what in >>DOS will do the same thing? Is it left to the Command.com, or is it >>left to each utility to do on its own? >Each program has to do it on its own. This is actually much worse >than COMMAND.COM doing it for you, because then you have differing >interpretations of things like "*89.*" (does it mean "*.*", like >COMMAND.COM thinks it does, or "any file with `89' in the name", >like some other utilities do?), plus the bother of having to code the >wildcard handling into programs that you write. WRONG!!! Each program *may* do its own thing, but DOS does not *require* it. Command.com passes the parameter directly to interrupt 21h functions 4Eh (find first matching file) and 4Fh (find next matching file). If a programmer does not like the DOS interpretation, he/she is free to interpret the wildcard directly and then pass the processed filenames to DOS. --------------------------------------------------------------------- Don Subt The opinions expressed above are Tandy Corp. strictly mine, not my employer's. 817-390-3068 ...!texbell!letni!rwsys!trsvax!don
Ralf.Brown@B.GP.CS.CMU.EDU (09/21/89)
In article <2517ACC9.28246@maccs.dcss.mcmaster.ca>, cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) wrote: > On the other hand, if you try to rename or delete a group of files, >this is not done by DOS; DOS requires a single file name for this. COMMAND >(or any program you write) has to, in this case, translate *.* into a >series of filenames (this is done with the find first/find next calls). Only if you use the handle versions of the rename or delete calls. The FCB versions have no problem handling multiple wildcarded files, but only work in the current directory. COMMAND.COM switches directories, uses the FCB call to rename or delete files, and then switches back to the original directory. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? "All through human history, tyrannies have tried to enforce obedience by prohibiting disrespect for the symbols of their power. The swastika is only one example of many in recent history." -- American Bar Association task force on flag burning
slimer@trsvax.UUCP (09/23/89)
If you are wanting to pass parameters with wildcards, ei. FOOBAR *.*. You will have to expand this yourself by using argv[1]. Unless of course you are using Borland Turbo C in which case you simply link in the wildcard.obj code contained on the distribution diskettes. This object code will automatically expand wildcard parameters into a list of filenames. **************************************************************************** * Thank You, texbell!letni!rwsys!trsvax!slimer * * Bill "My micro doesn't give a sheet!" - ComputerWorld * * George W. Pogue, 1300 Two Tandy, Fort Worth, TX. 76102 (817) 390-2871 * ****************************************************************************
iiitsh@cybaswan.UUCP (Steve Hosgood) (09/23/89)
In article <667@suntops.Tops.Sun.COM> rdas@hatter.tops.sun.com (Robin Das) writes: >In article <32164@ames.arc.nasa.gov> gahooten@titan (Gregory A. Hooten) writes: >>In Unix, it is the shell that interprets the character *, what in >>DOS will do the same thing? > >COMMAND.COM does the * and ? processing in DOS. Sorry - wrong! COMMAND.COM passes * and ? to the user program. Since the user- program then has to expand them, DOS supplies a pair of system-calls to let user-programs do it fairly easily. These are calls $4E (Find First) and $4F (Find Next). There is also an archaic pair, calls $11 (Find First) and $12 (Find Next) left over from the early days. These don't support full pathnames though. >... If you want a program to >do the same type of thing, the program must include the smarts. This is true enough. The reason is that a parent process can only pass 128 characters to a child on the command line. If COMMAND.COM expanded *.* as UNIX's shell does, then this 128 char barrier would regularly be hit. ******** ADVERT FOLLOWS: There is a TSR in comp.binaries.ibm.pc called 'WILDUNIX', which intercepts calls to DOS functions $4E and $4F, and causes them to treat wildcards in the UNIX manner. For instance "[a-j]*.exe" would be OK. This doesn't work unless the utility being run uses DOS to expand wildcards. Some of them 'do it by hand' so to speak. Also, some old programs call functions $11 and $12 instead, and they can't be intercepted either. However, if your program uses $4E and $4F cleanly, WILDUNIX will allow it to be driven a la UNIX. I've been running it on my machine for months and it works fine with all the UNIX-lookalike utilities I run. -----------------------------------------------+------------------------------ Steve Hosgood BSc, | Phone (+44) 792 295213 Image Processing and Systems Engineer, | Fax (+44) 792 295532 Institute for Industrial Information Techology,| Telex 48149 Innovation Centre, University of Wales, | JANET: iiitsh@uk.ac.swan.pyr Swansea SA2 8PP | UUCP: ..!ukc!cybaswan!iiitsh -----------------------------------------------+------------------------------ My views are not necessarily those of my employers! Please note the change in my username as of 1 Aug '89