«

I've just discovered that a single command line argument containing
wildcards, such as *.c, is expanded to a full list of matching files before
it gets to main().

That isn't really what I want (and there could be thousands of matching
files, which I may not want to deal with in my C program, but pass on to
something else, or the argument may not be a file specification at all).

Is there any way this behaviour can be changed, without needing to write
arguments in a special way?

(On Windows, I can choose to use the WinMain entry point instead; but this
won't work under Linux, assuming that that also expands.)

--
Bartc

On 10/01/2013 21:58, BartC wrote:
> I've just discovered that a single command line argument containing
> wildcards, such as *.c, is expanded to a full list of matching files before
> it gets to main().
>
> That isn't really what I want (and there could be thousands of matching
> files, which I may not want to deal with in my C program, but pass on to
> something else, or the argument may not be a file specification at all).
>
> Is there any way this behaviour can be changed, without needing to write
> arguments in a special way?
>
> (On Windows, I can choose to use the WinMain entry point instead; but
> this won't work under Linux, assuming that that also expands.)
>

put the argument between quotes

===pu@pumbair:~:502=== echo *
Calibre Library Desktop Documents Downloads Dropbox Library Movies Music
Pictures Projects Public Sites Software System test

===pu@pumbair:~:503=== echo "*"
*

===pu@pumbair:~:504=== echo '*'
*

BartC wrote:
) I've just discovered that a single command line argument containing
) wildcards, such as *.c, is expanded to a full list of matching files before
) it gets to main().

It gets expanded even before the program is started, by the shell.

) That isn't really what I want (and there could be thousands of matching
) files, which I may not want to deal with in my C program, but pass on to
) something else, or the argument may not be a file specification at all).
)
) Is there any way this behaviour can be changed, without needing to write
) arguments in a special way?

No.

) (On Windows, I can choose to use the WinMain entry point instead; but this
) won't work under Linux, assuming that that also expands.)

On Windows, the main() should not get the expanded arguments either, unless
you use some kind of special C compiler that adds extra code for the
expanding.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

"Willem" <> wrote in message
news:...
> BartC wrote:
> ) I've just discovered that a single command line argument containing
> ) wildcards, such as *.c, is expanded to a full list of matching files
> before
> ) it gets to main().

> ) (On Windows, I can choose to use the WinMain entry point instead; but
> this
> ) won't work under Linux, assuming that that also expands.)
>
> On Windows, the main() should not get the expanded arguments either,
> unless
> you use some kind of special C compiler that adds extra code for the
> expanding.

I use gcc. Other compilers, I've just seen, don't do it. Presumably gcc is
anyway just mirroring the behaviour of its 'home' system.

BTW, using quotes doesn't have the effect, in Windows, that 'pu' suggested.
Not that that is too practical anyway.

However, I've just found out from somewhere that having this line somewhere
in my program:

int _CRT_glob = 0;

fixes the problem in Windows!

It sounds like it will still be a problem under Linux, and my program had
better be prepared for being potentially offered a million parameters
instead of the one or two it might expect! (Was this automatic expansion, of
something which might not even be a file-spec, ever considered a good idea
in Linux?)

--
Bartc

On Thu, 2013-01-10, BartC wrote:
....
> It sounds like it will still be a problem under Linux, and my program had
> better be prepared for being potentially offered a million parameters
> instead of the one or two it might expect! (Was this automatic expansion, of
> something which might not even be a file-spec, ever considered a good idea
> in Linux?)

It has been considered a good idea on Unix for 40 years, and it's not
going to change. Best is if you can stop seeing it as a problem!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On 13-01-10 01:34 PM, BartC wrote:
> "Willem" <> wrote in message
> news:...
>> BartC wrote:
>> ) I've just discovered that a single command line argument containing
>> ) wildcards, such as *.c, is expanded to a full list of matching files
>> before
>> ) it gets to main().
>
>> ) (On Windows, I can choose to use the WinMain entry point instead; but
>> this
>> ) won't work under Linux, assuming that that also expands.)
>>
>> On Windows, the main() should not get the expanded arguments either,
>> unless
>> you use some kind of special C compiler that adds extra code for the
>> expanding.
>
> I use gcc. Other compilers, I've just seen, don't do it. Presumably gcc is
> anyway just mirroring the behaviour of its 'home' system.
>
> BTW, using quotes doesn't have the effect, in Windows, that 'pu' suggested.
> Not that that is too practical anyway.
>
> However, I've just found out from somewhere that having this line somewhere
> in my program:
>
> int _CRT_glob = 0;
>
> fixes the problem in Windows!
>
> It sounds like it will still be a problem under Linux, and my program had
> better be prepared for being potentially offered a million parameters
> instead of the one or two it might expect! (Was this automatic
> expansion, of
> something which might not even be a file-spec, ever considered a good idea
> in Linux?)
>

It's a feature not a problem. It's part of the shell you are running -
I'm guessing bash? You can use the built-in set and turn it off:

set -o noglob

BartC <> wrote:

> I've just discovered that a single command line argument containing
> wildcards, such as *.c, is expanded to a full list of matching files before
> it gets to main().

> That isn't really what I want (and there could be thousands of matching
> files, which I may not want to deal with in my C program, but pass on to
> something else, or the argument may not be a file specification at all).

> Is there any way this behaviour can be changed, without needing to write
> arguments in a special way?

Not by the program.

If you use csh or tcsh, put

set noglob

into your .cshrc file.

If you use bash, you need a different command in your .bashrc,
which someone else will tell you about.

> (On Windows, I can choose to use the WinMain entry point instead; but this
> won't work under Linux, assuming that that also expands.)

On Windows, if it is done it is done by the C startup routines
before they call main.

In unix/Linux or any unix-like system it is done before the program
is called.

Type

echo *

as an example. (The echo command prints its arguments.)

The other way is to write your own shell.

-- glen

"Greg Martin" <> wrote in message
news:_1HHs.63$...
> On 13-01-10 01:34 PM, BartC wrote:

>> It sounds like it will still be a problem under Linux

> It's a feature not a problem.

Suppose a program expects two parameters, both of which contain wildcards.
The result will be a single list of files; how to tell where the first set
of files ends, and the next begins? Or the second parameter should be a
single file; how to tell whether that parameter was present? Etc.

> It's part of the shell you are running - I'm guessing bash? You can use
> the built-in set and turn it off:
>
> set -o noglob

I've have a look later. If that works, that's good. But I can see problems:
it'll work on my system, but someone else running my program will also have
to do that set command. And it might stop other programs working properly
that expect the expansion.

--
Bartc

On Thursday 10 January 2013 17:32, in comp.lang.c, wrote:

> "Greg Martin" <> wrote in message
> news:_1HHs.63$...
>> On 13-01-10 01:34 PM, BartC wrote:
>
>>> It sounds like it will still be a problem under Linux
>
>> It's a feature not a problem.
>
> Suppose a program expects two parameters, both of which contain wildcards.
> The result will be a single list of files; how to tell where the first set
> of files ends, and the next begins? Or the second parameter should be a
> single file; how to tell whether that parameter was present? Etc.
>
>> It's part of the shell you are running - I'm guessing bash? You can use
>> the built-in set and turn it off:
>>
>> set -o noglob
>
> I've have a look later. If that works, that's good. But I can see
> problems: it'll work on my system, but someone else running my program
> will also have to do that set command. And it might stop other programs
> working properly that expect the expansion.

Please note that you are asking for a change of behaviour in the execution
environment, that is outside of the scope of the C language. Filename
globbing (or lack of it) is not part of the C standard; if you require your
program to perform it's own globbing, then you must use some utility
(likely an API) that is outside of the C standard. Each execution
environment will have it's own unique support, or perhaps no support at
all, for program-directed globbing.

Also note that, in most environments, the behaviour that you are asking for
is governed by well-known options /in that environment/. In POSIX/SUS
environments, globbing is done by the shell, and the facilities to disable
globbing are well known (set -o noglob, or even singlequoting the
argument).

You are trying to address a human-factors problem ("how to know to turn off
globbing when using this program") with code; never a good idea.

Here's the best advice:

** DOCUMENT THE REQUIREMENT IN THE OPERATING INSTRUCTIONS **

Wasn't that simple?

HTH
--
Lew Pitcher
"In Skills, We Trust"

On Thursday, January 10, 2013 2:32:23 PM UTC-8, Bart wrote:
> "Greg Martin" <> wrote in message news:_1HHs.63$... > On 13-01-10 01:34 PM, BartC wrote: >> It sounds like it will still be a problem under Linux > It's a feature not a problem. Suppose a program expects two parameters, both of which contain wildcards. The result will be a single list of files; how to tell where the first set of files ends, and the next begins? Or the second parameter should be a single file; how to tell whether that parameter was present? Etc. > It's part of the shell you are running - I'm guessing bash? You can use > the built-in setand turn it off: > > set -o noglob I've have a look later. If that works, that's good. But I can see problems: it'll work on my system, but someone else running my program will also have to do that set command. And it might stop other programs working properly that expect the expansion. -- Bartc

As others have said, it isw the shell that is doing this, not your program.
Users must be aware of the shell they are using, and use it appropriately.

If you want your program to receive two parameters containing wildcards
such as
a*b
cc*d

then execute the program properly:
myProgram 'a*b' 'cc*d'
--
Fred K