davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/29/88)
The WILDCARD program seems like a good addition, but I suspect that
there are a number of people who don't know that simple cases of this
can be done directly in the CLI.
for %n in (*.c) do beautify %n
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mebright@Data-IO.COM (Walter Bright) (07/30/88)
In article <11675@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
< The WILDCARD program seems like a good addition, but I suspect that
<there are a number of people who don't know that simple cases of this
<can be done directly in the CLI.
< for %n in (*.c) do beautify %n
Yeah, but I prefer wildcard because the syntax is easier to remember,
and a lot less typing.wsiebeck@rmi.UUCP (Wolfgang Siebeck) (07/30/88)
In article <11675@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
:
: for %n in (*.c) do beautify %n
:
Hi! You will get a problem, if Your 'beautify' creates .BAK-Files.
I guess DOS does the following:
- Look up first matching filename
- Pass it to beautify
- beautify renames input to *.BAK, and creates a new file *.C, which
is positioned at the end of the directory.
- DOS looks up the next matching name ...
I tried "for %i in (*.txt) do ws %i", and after editing one of the files
for the third time, I had to use ctrl-alt-del ....
So: there is a need for a 'real' wildcarder ...
-wsav@utacs.UTA.FI (Arto Viitanen) (07/31/88)
In article <1622@dataio.Data-IO.COM> bright@Data-IO.COM.Data-IO.COM (Walter Bright) writes: >In article <11675@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >< for %n in (*.c) do beautify %n > >Yeah, but I prefer wildcard because the syntax is easier to remember, >and a lot less typing. I have not read the source of the program, but with my own similar program I had some problems, what ``for'' command does not have. When I used my program (called do) to unpack ARC-files taken from net using command line do *.arc pkxarc ^1 first archivefile was handled ok, but after that system hang up. Finally I found the reason: ``do'' used DOS's FINDFIRST-function to parse wildcard and executed pxarc with first matching filename. But pkxarc created several new files, so directory no more matched the parsed wildcard, so next FINDNEXT-function searched for file, which wasn't in same place in directory, as it was with FINDFIRST. With ``for'' command, there is no such problems.
bright@Data-IO.COM (Walter Bright) (08/02/88)
In article <546@utacs.UTA.FI> av@utacs.UUCP (Arto Viitanen) writes:
<When I used my program (called do) to unpack ARC-files taken from net using
<command line
< do *.arc pkxarc ^1
<first archivefile was handled ok, but after that system hang up. Finally I
<found the reason: ``do'' used DOS's FINDFIRST-function to parse wildcard
<and executed pxarc with first matching filename. But pkxarc created
<several new files, so directory no more matched the parsed wildcard, so
<next FINDNEXT-function searched for file, which wasn't in same place in
<directory, as it was with FINDFIRST.
<With ``for'' command, there is no such problems.
The WILDCARD program I wrote doesn't suffer from those problems either.
The reason is that *all* the wildcard expansion is done *prior* to executing
the command, so if the command changes the files or the directory, the
wildcard expansion is not affected.emb978@leah.Albany.Edu (Eric M. Boehm) (08/03/88)
In article <1623@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes: > In article <546@utacs.UTA.FI> av@utacs.UUCP (Arto Viitanen) writes: > <When I used my program (called do) to unpack ARC-files taken from net using > <command line > < do *.arc pkxarc ^1 pkxarc * would have done what you intended without any need for any auxiliary program Eric M. Boehm EMB978@ALBNY1VX.BITNET EMB978@LEAH.ALBANY.EDU