Asterisk expansion...

Asterisk expansion...

[Robertson, Jason V]

Hi,

There seems to be an inconsistency in how * is interpreted.  When you
run, say, 'echo.exe' from the commandline you get the following:
C:> echo *.*
<Contents of C: are listed>
C:> echo \*.\*
\*.\*

So why does it expand the glob in the first instance, and not unescape
them in the second?  And doesn't this mean it's impossible to echo the
string:
*.*
from cmd?

Running from sh behaves as expected:
$ echo *.*
<contents of pwd are listed>
$ echo \*.\*
*.*

Any ideas?  The reason this is causing problems is that we have a
wrapper around these binaries and it's clueless as to what's expected of
it because it seems indeterminate with respect to commandline expansion.
Is there some hook whereby the tools know if they're being run from
another Cygnus tool so they don't expand the command line?

Thanks,
Jason
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Matthias Morche]

Robertson, Jason V wrote:
...
> There seems to be an inconsistency in how * is interpreted.  When you
> run, say, 'echo.exe' from the commandline you get the following:
> C:> echo *.*
> <Contents of C: are listed>
> C:> echo \*.\*
> \*.\*
> 
> So why does it expand the glob in the first instance, and not unescape
> them in the second?  And doesn't this mean it's impossible to echo the
> string:
> *.*
> from cmd?
...

Did You ever try:
c:> echo "*.*"
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Mike Bandy]

On Thu, 23 Jul 1998, Robertson, Jason V wrote:

> There seems to be an inconsistency in how * is interpreted.  When you
> run, say, 'echo.exe' from the commandline you get the following:
> C:> echo *.*
> <Contents of C: are listed>
> C:> echo \*.\*
> \*.\*
> 
> So why does it expand the glob in the first instance, and not unescape
> them in the second?  And doesn't this mean it's impossible to echo the
> string:
> *.*
> from cmd?

echo '*.*'

Strings put in single quotes are not expanded by the shell.

	Mike
--
Mike Bandy                  |  As cool as the pale wet leaves
michael.bandy@jhuapl.edu    |                  of lily-of-the-valley
Johns Hopkins University    |  She lay beside me in the dawn.
Applied Physics Laboratory  |      -Ezra Pound

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Michael Hirmke]

Hi Robertson,,

>Hi,
>
>There seems to be an inconsistency in how * is interpreted.  When you
>run, say, 'echo.exe' from the commandline you get the following:
C:>> echo *.*
><Contents of C: are listed>
C:>> echo \*.\*
>\*.\*
>
>So why does it expand the glob in the first instance, and not unescape
>them in the second?  And doesn't this mean it's impossible to echo the
>string:
>*.*
>from cmd?

You are assuming, that command.com / cmd.exe are using \ to escape
characters, which isn't the case. At best DOS shells would assume, that
you want to list all files in all directories, when you type \*.\* -
because \ is the path separator!

[...]
>Thanks,
>Jason

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Fergus Henderson]

On 24-Jul-1998, Michael Hirmke <mh@mike.franken.de> wrote:
> Hi Robertson,,
> 
> >There seems to be an inconsistency in how * is interpreted.  When you
> >run, say, 'echo.exe' from the commandline you get the following:
> C:>> echo *.*
> ><Contents of C: are listed>
> C:>> echo \*.\*
> >\*.\*
> >
> >So why does it expand the glob in the first instance, and not unescape
> >them in the second?  And doesn't this mean it's impossible to echo the
> >string:
> >*.*
> >from cmd?
> 
> You are assuming, that command.com / cmd.exe are using \ to escape
> characters, which isn't the case.

No; he is assuming that gnu-win32 should use \ to escape characters.
After all, it is gnu-win32 that is doing the globbing (expanding the
wildcards), not command.com or cmd.exe.

However, gnu-win32 uses quotes rather than \ to escape the globbing
mechanism.  This seems like a reasonable design choice, given the 
use of "\" in DOS style path names.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

OT: Re: Asterisk expansion...[Was: unsubscribe]....

[Björn Kulms]

Could you guys, by any chance, read (or RTFM to) 
any dummy-beginner's guide to UNIX or at least,
PLEASE answer personally instead of reposting to the list.

BTW, good stile is, to mark off-topic stuff "OT:".

Stuff (like this) is not related to cygwin32 at all,
but knowledge that is available to the public since 
decades, and there are bunches of newsgroups etc.
that actually deal with those questions.

BTW, you might want to have some LinuX installation
around. Helps a lot....

> There seems to be an inconsistency in how * is interpreted.  When you
> run, say, 'echo.exe' from the commandline you get the following:
> C:> echo *.*
> <Contents of C: are listed>
> C:> echo \*.\*
> \*.\*
>
> So why does it expand the glob in the first instance, and not unescape
> them in the second?  And doesn't this mean it's impossible to echo the
> string:
> *.*
> from cmd?
>
> Running from sh behaves as expected:
> $ echo *.*
> <contents of pwd are listed>
> $ echo \*.\*
> *.*
>
> Any ideas?  The reason this is causing problems is that we have a
> wrapper around these binaries and it's clueless as to what's expected of
> it because it seems indeterminate with respect to commandline expansion.
> Is there some hook whereby the tools know if they're being run from
> another Cygnus tool so they don't expand the command line?
>
> Thanks,
> Jason
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".



--
BGKS Bjoern Kulms        Tel. +49(3677)670014    Tel. +49(5363)71468
TU Ilmenau               Max-Planck-Ring 8c/L62  Kronekenberg 1
Elektron. Medientechnik  D 98693 Ilmenau         D 38446 Wolfsburg


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Earnie Boyd]

---"Robertson, Jason V"  wrote:
>
> Hi,
> 
> There seems to be an inconsistency in how * is interpreted.  When you
> run, say, 'echo.exe' from the commandline you get the following:
> C:> echo *.*
> <Contents of C: are listed>
> C:> echo \*.\*
> \*.\*
> 
> So why does it expand the glob in the first instance, and not unescape
> them in the second?  And doesn't this mean it's impossible to echo the

It is the shells job to do the globbing not the programs.

the \ is not used the same way in MSDOS as it is in UNIX the program
will only output to stdout what it receives on stdin.

This is true for _ALL_ programs.

<snip>


==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Fergus Henderson]

On 24-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> ---"Robertson, Jason V"  wrote:
> >
> > Hi,
> > 
> > There seems to be an inconsistency in how * is interpreted.  When you
> > run, say, 'echo.exe' from the commandline you get the following:
> > C:> echo *.*
> > <Contents of C: are listed>
> > C:> echo \*.\*
> > \*.\*
> > 
> > So why does it expand the glob in the first instance, and not unescape
> > them in the second?
> 
> It is the shells job to do the globbing not the programs.

Then why does gnu-win32 do the globbing in the case of the command
`echo *.*'?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Leo Mauro]

On Saturday, July 25, 1998 04:14 AM Fergus Henderson wrote:

> > > So why does it expand the glob in the first instance, and not unescape
> > > them in the second?
> >
> > It is the shells job to do the globbing not the programs.
>
> Then why does gnu-win32 do the globbing in the case of the command
> `echo *.*'?

Every program using the cygwin32 DLL includes startup code to check
whether it is running under a shell also using cygwin32.  If so, the code
assumes the shell already did argument globbing at it leaves the arg
list alone.  If not, the startup code does the argument processing and
globbing itself (it assumes the program is running under COMMAND.COM
or CMD.EXE).  This allows programs to take "wildcard" arguments
regardless of the shell they're running under.

Leo Mauro
Principal Scientist
TeleSys Technologies, Inc.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Jason V Robertson]

All,

I found a solution to my problem.

If you're curious - the application involved was a wrapper binary that
performs version control functions.  So you can control which version of,
say, 'bash.exe' gets run when you type 'bash' at the commandline.  The
problem was that since the wrapper wasn't a Cygnus binary (it's native
Win32) it provided an artificial layer between a Cygnus parent and a Cygnus
child.  So if I have a script that calls 'echo \*.\*' echo would see that it
doesn't have a Cygnus parent (the wrapper) and improperly glob the argument.

To get around it I have the wrapper determine if it's a Cygnus binary and if
it is it sets a variable.  If a new wrapper process sees that variable it
calls SetEnvironmentVariable(..) to append 'noglob' to CYGWIN32.

Anyway, thank you all for your help.

Jason

> -----Original Message-----
> From: Robert Read [ mailto:rread@home.com ]
> Sent: Friday, July 24, 1998 6:59 PM
> To: Robertson, Jason V
> Subject: Re: Asterisk expansion...
>
>
> Your problem is that unix tools don't expand globs; the shell does all
> of that work.
>
> So when you are using the unix shell and you type this command:
>
> $ echo *
>
> The shell will look for files in the current directory and replace the
> '*' with all the filenames.  Then it executes echo with the filenames
> arguments.
>
> So, one way to do what you want is to execute the commands by using the
> shell.  On unix, I believe this is done with the system() function.  If
> that doesn't work, then your wrapper can execute the shell directly like
> this:
>
>   function_to_run_program("bash.exe -c program.exe *");
>
> robert
>
> Robertson, Jason V wrote:
> >
> > Hi,
> >
> > There seems to be an inconsistency in how * is interpreted.  When you
> > run, say, 'echo.exe' from the commandline you get the following:
> > C:> echo *.*
> > <Contents of C: are listed>
> > C:> echo \*.\*
> > \*.\*
> >
> > So why does it expand the glob in the first instance, and not unescape
> > them in the second?  And doesn't this mean it's impossible to echo the
> > string:
> > *.*
> > from cmd?
> >
> > Running from sh behaves as expected:
> > $ echo *.*
> > <contents of pwd are listed>
> > $ echo \*.\*
> > *.*
> >
> > Any ideas?  The reason this is causing problems is that we have a
> > wrapper around these binaries and it's clueless as to what's expected of
> > it because it seems indeterminate with respect to commandline expansion.
> > Is there some hook whereby the tools know if they're being run from
> > another Cygnus tool so they don't expand the command line?
> >
> > Thanks,
> > Jason
> > -
> > For help on using this list (especially unsubscribing), send a
> message to
> > "gnu-win32-request@cygnus.com" with one line of text: "help".
>

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Michael Weiser]

Hi Jason,

You wrote:

>To get around it I have the wrapper determine if it's a Cygnus binary and if
>it is it sets a variable.  If a new wrapper process sees that variable it
>calls SetEnvironmentVariable(..) to append 'noglob' to CYGWIN32.
Why not recompile the wrapper using cygwin's gcc so that it becomes a
cygwin executable?

bye

Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Earnie Boyd]

---Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
>
> On 24-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> > ---"Robertson, Jason V"  wrote:
> > >
> > > Hi,
> > > 
> > > There seems to be an inconsistency in how * is interpreted. 
When you
> > > run, say, 'echo.exe' from the commandline you get the following:
> > > C:> echo *.*
> > > <Contents of C: are listed>
> > > C:> echo \*.\*
> > > \*.\*
> > > 
> > > So why does it expand the glob in the first instance, and not
unescape
> > > them in the second?
> > 
> > It is the shells job to do the globbing not the programs.
> 
> Then why does gnu-win32 do the globbing in the case of the command
> `echo *.*'?

In the case of the DOS shell command `ECHO' or `echo' is a shell
builtin; therefore, gnu-win32 doesn't even enter the picture.  In the
case of the bash shell command `echo' is a shell builtin and globbing
happens as expected.  Yes, I know there is an echo.exe; but, unless
you explicitely execute it you execute the builtin command.

To answer your question though, gnu-win32 globs the command line again
so that the filesystem emulation can happen rather seamlessly.

You responded to Michael Hirmke:
> No; he is assuming that gnu-win32 should use \ to escape characters.
> After all, it is gnu-win32 that is doing the globbing (expanding the
> wildcards), not command.com or cmd.exe.

This is an incorrect statement due to the first fact I stated.  When
doing `echo \*.\*' within the DOS shell the globbing that occurs
within cmd.exe or command.com will not find a file and then returns
\*.\* to echo as the parameter list which it will simply write to stdout.
==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Fergus Henderson]

On 27-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> 
> ---Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> >
> > On 24-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> > > ---"Robertson, Jason V"  wrote:
> > > >
> > > > Hi,
> > > > 
> > > > There seems to be an inconsistency in how * is interpreted.  When you
> > > > run, say, 'echo.exe' from the commandline you get the following:
> > > > C:> echo *.*
> > > > <Contents of C: are listed>
> > > > C:> echo \*.\*
> > > > \*.\*
> > > > 
> > > > So why does it expand the glob in the first instance, and not unescape
> > > > them in the second?
> > > 
> > > It is the shells job to do the globbing not the programs.
> > 
> > Then why does gnu-win32 do the globbing in the case of the command
> > `echo *.*'?
>
> In the case of the DOS shell command `ECHO' or `echo' is a shell
> builtin; therefore, gnu-win32 doesn't even enter the picture.

Sorry, you are correct.  I forgot that echo was a builtin for command.com.
Let me rephrase the question: why does gnu-win32 do the globbing in the
case of the command `C:\bin\echo *.*'?

My point is that your statement "It is the shells job to do the globbing
not the programs", while valid in Unix, is not valid in DOS, and it
is not valid in any unqualified sense in gnu-win32.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Earnie Boyd]

---Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
>
> On 27-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> > 
> > ---Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> > >
> > > On 24-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> > > > ---"Robertson, Jason V"  wrote:
> > > > >
> > > > > Hi,
> > > > > 
> > > > > There seems to be an inconsistency in how * is interpreted. 
When you
> > > > > run, say, 'echo.exe' from the commandline you get the
following:
> > > > > C:> echo *.*
> > > > > <Contents of C: are listed>
> > > > > C:> echo \*.\*
> > > > > \*.\*
> > > > > 
> > > > > So why does it expand the glob in the first instance, and
not unescape
> > > > > them in the second?
> > > > 
> > > > It is the shells job to do the globbing not the programs.
> > > 
> > > Then why does gnu-win32 do the globbing in the case of the command
> > > `echo *.*'?
> >
> > In the case of the DOS shell command `ECHO' or `echo' is a shell
> > builtin; therefore, gnu-win32 doesn't even enter the picture.
> 
> Sorry, you are correct.  I forgot that echo was a builtin for
command.com.
> Let me rephrase the question: why does gnu-win32 do the globbing in
the
> case of the command `C:\bin\echo *.*'?
> 
> My point is that your statement "It is the shells job to do the
globbing
> not the programs", while valid in Unix, is not valid in DOS, and it
> is not valid in any unqualified sense in gnu-win32.
> 

I know from the experience of my mingw32-sup package that cmd.exe and
commmand.com do globbing, it is not as robust though.  For example:
`ls' doesn't do any globbing, it only reports on a list of files given
it on stdin.  I ported it to native win32 using mingw32.

Gnu-win32 reglobs in the startup of the program (none of the programs
were modified to do the globbing) in order to emulate the UNIX
environment and to serve the `mounted filesystem table'.
==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Fergus Henderson]

On 27-Jul-1998, Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> ---Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> > My point is that your statement "It is the shells job to do the globbing
> > not the programs", while valid in Unix, is not valid in DOS, and it
> > is not valid in any unqualified sense in gnu-win32.
> 
> I know from the experience of my mingw32-sup package that cmd.exe and
> commmand.com do globbing, it is not as robust though.

It has nothing to do with robustness.  `cmd.exe' and `command.com' do
globbing only for their builtin commands, because according to the DOS
design it is the program's responsibility to do globbing, not the
shell's.  This design is in fact *more* robust (although arguably less
flexible) than the Unix design, because it problems with commands such
as `cp *.c' sometimes silently doing the wrong thing instead of
reporting an error message.

(The reason that the Unix design is arguably more flexible is that it
allows you to change the globbing syntax by simply changing shells.)

> For example:
> `ls' doesn't do any globbing, it only reports on a list of files given
> it on stdin.  I ported it to native win32 using mingw32.

If you didn't add code to `ls' to glob-expand its arguments as part
of that port, then you didn't do a complete port, and the problem
is thus best ascribed to a bug in your port, not to any lack of robustness
in the way DOS handles globbing.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Robertson, Jason V]

I thought of that but didn't want to pay the performance penalty or have to
worry about yet another dependency (the Cygnus DLL).  Although that may have
helped (or it may not have) with a strange console problem I have - I have
to Wait on all children that use the console because if I don't for some
reason the child loses access to the console.  I guess 'cmd' sees that its
direct child has exited so tries to take it back over or something.

Thanks,
Jason

> -----Original Message-----
> From:	michael@weiser.saale-net.de [SMTP:michael@weiser.saale-net.de]
> Sent:	Monday, July 27, 1998 9:31 AM
> To:	Jason V Robertson
> Cc:	gnu-win32@cygnus.com
> Subject:	Re: Asterisk expansion...
> 
> Hi Jason,
> 
> You wrote:
> 
> >To get around it I have the wrapper determine if it's a Cygnus binary and
> if
> >it is it sets a variable.  If a new wrapper process sees that variable it
> >calls SetEnvironmentVariable(..) to append 'noglob' to CYGWIN32.
> Why not recompile the wrapper using cygwin's gcc so that it becomes a
> cygwin executable?
> 
> bye
> 
> Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Asterisk expansion...

[Michael Weiser]

Hi Jason,

You wrote:

>I thought of that but didn't want to pay the performance penalty or have to
>worry about yet another dependency (the Cygnus DLL).  Although that may have
>helped (or it may not have) with a strange console problem I have - I have
You paid the price of a long bug search and quick'n'dirty fix for it.
:)

>to Wait on all children that use the console because if I don't for some
>reason the child loses access to the console.  I guess 'cmd' sees that its
>direct child has exited so tries to take it back over or something.
With cygwin you can use all normal Win32 API calls that your wrapper
uses too. IMHO you shouldn't have to change anything on your code
which should cause it to work almost exactly the same even though
compiled as a cygwin32 executable. Or am I missing something
important?

bye

Michael
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Andrew Dalgleish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

> I know from the experience of my mingw32-sup package that cmd.exe and
> commmand.com do globbing, it is not as robust though.  For example:
> `ls' doesn't do any globbing, it only reports on a list of files given
> it on stdin.  I ported it to native win32 using mingw32.
[Andrew Dalgleish]  
cmd/command do NOT do globbing.

Some compiler/linker packages may do globbing in the run-time startup
code, so from your code it seems as if the globbing had been done by the
shell.

I can't speak for mingw32, but from the Microsoft help:

Expanding Wildcard Arguments 
Microsoft Specific ®

When running a C program, you can use either of the two wildcards - the
question mark (?) and the asterisk (*) - to specify filename and path
arguments on the command line. 

Command-line arguments are handled by a routine called _setargv (or
_wsetargv in the wide-character environment), which by default does not
expand wildcards into separate strings in the argv string array. You can
replace the normal _setargv routine with a more powerful version of
_setargv that does handle wildcards by linking with the SETARGV.OBJ
file. If your program uses a wmain function, link with WSETARGV.OBJ. 

To link with SETARGV.OBJ or WSETARGV.OBJ, use the /link option. For
example: 

cl typeit.c /link setargv.obj

The wildcards are expanded in the same manner as operating system
commands. (See your operating system user's guide if you are unfamiliar
with wildcards.) Enclosing an argument in double quotation marks (" ")
suppresses the wildcard expansion. Within quoted arguments, you can
represent quotation marks literally by preceding the
double-quotation-mark character with a backslash (\). If no matches are
found for the wildcard argument, the argument is passed literally. 

END Microsoft Specific

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Andrew Dalgleish]

> -----Original Message-----
> From:	Earnie Boyd [SMTP:earnie_boyd@yahoo.com]
> Sent:	1998 July 30, Thursday 00:29
> To:	Andrew Dalgleish
> Subject:	RE: Asterisk expansion...
> 
> 
> Thanks for this information.  I hate giving misinformation.  I have
> yet to find a definition of the function _setargv though.  I've built
> simple tests with both mingw32 gcc and with Jacob Navia's LCC and they
> both do the same globbing on NT 3.51.  I've searched the executables
> with `nm test.exe | less' and can only find argv as data which comes
> from the parameter definitions from main.  I've searched crtdll.dll
> with the strings command and did not find the _setargv function.
> 
> From the definition you've given below I can conclude the cmd.exe does
> infact do globbing. The statement
> 
> > The wildcards are expanded in the same manner as operating system
> > commands. (See your operating system user's guide if you are
> unfamiliar
> 
> implies to me that the * is expanded to a list of files by cmd.exe
> albeit only from the working directory.
[Andrew Dalgleish]  
cmd/command only do globbing for INTERNAL commands.
(For internal commands, it is a moot point as to whether the shell or
the command does the globbing.)

Microsoft use a function _setargv in their startup code.
The default version does NOT do any globbing.
They also offer a "more powerful version" which does do globbing, but
you need to specify the SETARGV.OBJ file in the link command.

I am not suprised you could not find any references to _setargv.
This function is Microsoft-specific, and if anyone else uses a function
with the same name it is just co-incidence.


Here is definitive proof  that cmd does NOT do globbing for external
commands unless you link with the alternative _setargv.
C:\>type ShowArgs.c
#include <stdio.h>
#include <stdlib.h>
int     main(int argc, char *argv[])
{
  int   ArgIndex;
  for (ArgIndex = 0; ArgIndex < argc; ++ArgIndex)
    printf("%d %s\n", ArgIndex, argv[ArgIndex]);
  return EXIT_SUCCESS;
}


C:\>cl ShowArgs.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 11.00.7022 for
80x86
Copyright (C) Microsoft Corp 1984-1997. All rights reserved.

ShowArgs.c
Microsoft (R) 32-Bit Incremental Linker Version 5.10.7303
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.

/out:ShowArgs.exe
ShowArgs.obj

C:\>ShowArgs *.c
0 ShowArgs
1 *.c

C:\>cl ShowArgs.c setargv.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 11.00.7022 for
80x86
Copyright (C) Microsoft Corp 1984-1997. All rights reserved.

ShowArgs.c
Microsoft (R) 32-Bit Incremental Linker Version 5.10.7303
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.

/out:ShowArgs.exe
ShowArgs.obj
setargv.obj

C:\>ShowArgs *.c
0 ShowArgs
1 SHOWARGS.C

C:\>

When linked with SETARGV.OBJ, the arguments are globbed.
When linked without SETARGV.OBJ, the arguments are NOT globbed.

Hence cmd/command do NOT do globbing for external commands

(Actually it is possible that globbing is done by the shell.
E.g. the shell could peek into the .EXE to detect which version of
SETARGV.OBJ was included.
I don't think this is very likely, but then it is Microsoft... :-)

Regards,
Andrew Dalgleish

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Earnie Boyd]

---Andrew Dalgleish <andrewd@axonet.com.au> wrote:
>
> 
> 
<snip>
> 
> When linked with SETARGV.OBJ, the arguments are globbed.
> When linked without SETARGV.OBJ, the arguments are NOT globbed.
> 
> Hence cmd/command do NOT do globbing for external commands
> 
> (Actually it is possible that globbing is done by the shell.
> E.g. the shell could peek into the .EXE to detect which version of
> SETARGV.OBJ was included.
> I don't think this is very likely, but then it is Microsoft... :-)
> 

It is also possible that cmd.exe/command.com does do the globbing and
that the default _setargv reads the command line and resets the argv
array.  I would do this if I had the MS compiler; but, try with this
sample code creating your own _setargv which simply does nothing
(maybe output a message so that you know that your _setargv was called).

Colin Peters and Jacob Navia, I hope you are reading this.  With the
startup code of Mingw32 or LCC is any default globbing done?

==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Asterisk expansion...

[Earnie Boyd]

---Andrew Dalgleish <andrewd@axonet.com.au> wrote:
>
> 
> 
> > -----Original Message-----
> > From:	Earnie Boyd [SMTP:earnie_boyd@yahoo.com]
> > Sent:	1998 July 30, Thursday 21:37
> > To:	gnu-win32@cygnus.com; Andrew Dalgleish
> > Subject:	RE: Asterisk expansion...
> > 
> > ---Andrew Dalgleish <andrewd@axonet.com.au> wrote:
> > >
> > > 
> > > 
> > <snip>
> > > 
> > > When linked with SETARGV.OBJ, the arguments are globbed.
> > > When linked without SETARGV.OBJ, the arguments are NOT globbed.
> > > 
> > > Hence cmd/command do NOT do globbing for external commands
> > > 
> > > (Actually it is possible that globbing is done by the shell.
> > > E.g. the shell could peek into the .EXE to detect which version of
> > > SETARGV.OBJ was included.
> > > I don't think this is very likely, but then it is Microsoft... :-)
> > > 
> > 
> > It is also possible that cmd.exe/command.com does do the globbing
and
> > that the default _setargv reads the command line and resets the argv
> > array.  I would do this if I had the MS compiler; but, try with this
> > sample code creating your own _setargv which simply does nothing
> > (maybe output a message so that you know that your _setargv was
> > called).
> [Andrew Dalgleish]  
> I've waded through Microsoft's run-time source.
> 
> SETARGV.OBJ contains a single function "_setargv".
> The default version does nothing.
> The globbing version sets a flag "_dowildcard" to one.
> 
> Later in the startup "__getmainargs" calls "__setargv".
> (It took me a while to realize this one has two leading underscores
:-)
> 
> If the flag is set "__setargv" then calls "_cwild".
> "_cwild" does some simple checks for quoted arguments (which are not
> expanded), and passes args which may be wildcards on to "tmatch".
> "tmatch" looks for the wildcard characters, then uses
> FindFirstFile/FindNextFile to build the list of files.
> 
> Most of these functions have two versions, one for char and one for
> wchar_t
> They use a single source with lots of #if's sprinkled around.
> For example "tmatch" is #defined to either "match" or "wmatch"
> 
> The bottom line - cmd/command do not glob.
> 
> 
> 

I found the following code from the init.c code for mingw32.  Note
that it has nothing to do with _setargv but it does confirm that
cmd/command _DO_NOT_GLOB_.

/* NOTE: Thanks to Pedro A. Aranda Gutiirrez <paag@tid.es> for pointing
 * this out to me. GetMainArgs (used below) takes a fourth argument
 * which is an int that controls the globbing of the command line. If
 * _CRT_glob is non-zero the command line will be globbed (e.g. *.*
 * expanded to be all files in the startup directory). In the mingw32
 * library a _CRT_glob variable is defined as being -1, enabling
 * this command line globbing by default. To turn it off and do all
 * command line processing yourself (and possibly escape bogons in
 * MS's globbing code) include a line in one of your source modules
 * defining _CRT_glob and setting it to zero, like this:
 *  int _CRT_glob = 0;
 */
extern int  _CRT_glob;

/*
 * Initialize the __argc, __argv and _environ variables.
 */
static void
_mingw32_init_mainargs ()
{
    /*
     * CRTDLL provides a nice little function for doing just that.
     * Convenient isn't it?
     * NOTE: The last
     */
    (void) __GetMainArgs(&__argc, &__argv, &_environ, _CRT_glob);
}

==
-        \\||//
---o0O0--Earnie--0O0o----
--earnie_boyd@yahoo.com--
------ooo0O--O0ooo-------



_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".