Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Command line arguments

Reply
Thread Tools

Command line arguments

 
 
BartC
Guest
Posts: n/a
 
      01-10-2013
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

 
Reply With Quote
 
 
 
 
pu
Guest
Posts: n/a
 
      01-10-2013
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 '*'
*

 
Reply With Quote
 
 
 
 
Willem
Guest
Posts: n/a
 
      01-10-2013
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
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-10-2013
"Willem" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-10-2013
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 .
 
Reply With Quote
 
Greg Martin
Guest
Posts: n/a
 
      01-10-2013
On 13-01-10 01:34 PM, BartC wrote:
> "Willem" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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

 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-10-2013
BartC <(E-Mail Removed)> 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
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-10-2013
"Greg Martin" <(E-Mail Removed)> wrote in message
news:_1HHs.63$(E-Mail Removed)...
> 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
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      01-10-2013
On Thursday 10 January 2013 17:32, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> "Greg Martin" <(E-Mail Removed)> wrote in message
> news:_1HHs.63$(E-Mail Removed)...
>> 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"
 
Reply With Quote
 
Fred K
Guest
Posts: n/a
 
      01-10-2013
On Thursday, January 10, 2013 2:32:23 PM UTC-8, Bart wrote:
> "Greg Martin" <(E-Mail Removed)> wrote in message news:_1HHs.63$(E-Mail Removed)... > 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Run Unix shell command $ parse command line arguments in python rkoida@yahoo.com Python 4 04-23-2005 04:42 AM
Documentation on command line arguments to perl Peter Kay Perl 1 05-18-2004 01:27 AM
command line arguments Ashe Corven C++ 3 05-08-2004 06:56 PM
How to hide command line arguments in a windows application SC C++ 2 05-05-2004 10:06 AM
Parser for command line arguments? Ahmed Moustafa Java 0 08-21-2003 05:21 AM



Advertisments