bob@gen1.UUCP (Robert Kamins) (02/11/88)
In <1282@nmtsun.nmt.edu>, greg@nmtsun.nmt.edu (Greg Lindhorst) writes: > I have a stupid question to ask. How can one get Turbo C to expand > wild carded arguments on the command line? > > I.E. Translate something like: "doitto *.c" > into something like: "doitto first_file.c second_file.c ..." The process of which you speak is called "globbing" and is normally handled in Unix by the shell. In MS-DOS-land, you get to do it all by yourself. I have a "glob" routine that does an MS-DOS wild-card expansion. The trouble with MS-DOS expansion is that you can't easily glob stuff like "*c" and expect to get files with names like "ab.c". What you WILL get is "abc.", "xyz." and in fact anything without an extension. Oh well, my glob is posted to "comp.binaries.ibm.pc" if you want it. You can "#include" it or compile it and add the object to your libraries. Bob Kamins.
mouse@mcgill-vision.UUCP (der Mouse) (03/07/88)
In article <329@gen1.UUCP>, bob@gen1.UUCP (Robert Kamins) writes: > In <1282@nmtsun.nmt.edu>, greg@nmtsun.nmt.edu (Greg Lindhorst) writes: >> How can one get Turbo C to expand wild carded arguments on the >> command line? > [In UNIX, this is done by the shell.] In MS-DOS-land, you get to do > it all by yourself. > I have a "glob" routine that does an MS-DOS wild-card expansion. The > trouble with MS-DOS expansion is that you can't easily glob stuff > like "*c" and expect to get files with names like "ab.c". Yes. And ugh. One weekend when I had MS-DOS inflicted on me, I started to write a glob routine that behaved sensibly. (It just told DOS to expand "*.*" in the appropriate directory and then filtered out what it wanted on its own.) It's not finished, but if enough people are desperate enough to want it, I can probably dig out and post the part that is finished. There is nothing inherently difficult about this; my main problem was that the machine I was on had no editor I would consider civilized. I was also using Microsoft's C compiler, that being what was available. (Not my machine; I would never be happy on anything that small.) The version I was using (I think it was version 4.something, for what that's worth) would bugcheck fairly easily, for example on the program main() { ((unsigned char far (*)[2])0xb0000000)[(0)+(80*(0))][0] = 0; } Yes, that mess resulted from a macro expansion, and yes, I was trying to write to screen memory. When either of the two (0) terms is replaced by a variable such as (i) or (j), the bugcheck disappeared. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
franka@mmintl.UUCP (Frank Adams) (03/25/88)
In article <977@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <329@gen1.UUCP>, bob@gen1.UUCP (Robert Kamins) writes: >> In <1282@nmtsun.nmt.edu>, greg@nmtsun.nmt.edu (Greg Lindhorst) writes: >> I have a "glob" routine that does an MS-DOS wild-card expansion. The >> trouble with MS-DOS expansion is that you can't easily glob stuff >> like "*c" and expect to get files with names like "ab.c". > >Yes. And ugh. One weekend when I had MS-DOS inflicted on me, I >started to write a glob routine that behaved sensibly. Please don't confuse "what I'm used to" with "sensible". For those of us who are accustomed to thinking of a file as a file name and a file type, it is Un*x which does not behave "sensibly". (And of the half dozen or so systems I have used, all but Un*x take this approach.) Note that if you want all your C files on MS-DOS, "*.c" works just fine. I don't think I have ever done a search where I wanted to match all and only file names ending in "c". On the other hand, with the name/extension paradigm, I can search for "*." and find all the files with no extension. No comparable Un*x search is possible. (With full regular expression searching, it is *possible*, but not worth it.) This should not be taken as a flame against Un*x -- simple file names permitting embedded "."s do have their advantages. Nor should it be taken as indicating that I consider MS-DOS a real operating system. All I'm saying is, try using the system as it was intended to be used, instead of as a brain-damaged version of something else. There are few design decisions so bad that one cannot make some sort of productive use of them. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
mouse@mcgill-vision.UUCP (der Mouse) (04/10/88)
In article <2785@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: > In article <977@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >> In article <329@gen1.UUCP>, bob@gen1.UUCP (Robert Kamins) writes: >>> In <1282@nmtsun.nmt.edu>, greg@nmtsun.nmt.edu (Greg Lindhorst) writes: >>> I have a "glob" routine that does an MS-DOS wild-card expansion. >>> The trouble with MS-DOS expansion is that you can't easily glob >>> stuff like "*c" and expect to get files with names like "ab.c". >> Yes. And ugh. One weekend when I had MS-DOS inflicted on me, I >> started to write a glob routine that behaved sensibly. > Please don't confuse "what I'm used to" with "sensible". [points out > that some think of filesnames as "name" + "type"] I wasn't making that mistake. Personally, I prefer the UNIX way, but I recognize that it is reasonable to treat names as split up in this way. However, suppose your directory contains A.C B.C FOOA.C FOOB.C BARA.C BARB.C and you glob *B.C. The sensible thing, which VMS and presumably most systems with name+type filenames do, is to produce B.C FOOB.C BARB.C. MS-DOS gives you all six .C files. In fact, any pattern whose name portion (the part before the dot) begins with a * behaves as if there were nothing else in the name portion, I can tell. *This* you surely do not consider sensible. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu