Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #29906 > unrolled thread

Command line arguments

Back to article view | Back to comp.lang.c

Contents

  Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 20:58 +0000
    Re: Command line arguments pu <uselpa.list@gmail.com> - 2013-01-10 22:02 +0100
      Re: Command line arguments pu <uselpa.list@gmail.com> - 2013-01-11 14:43 +0100
        Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:10 +0000
    Re: Command line arguments Willem <willem@turtle.stack.nl> - 2013-01-10 21:02 +0000
      Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 21:34 +0000
        Re: Command line arguments Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-01-10 22:02 +0000
        Re: Command line arguments Greg Martin <greg@softsprocket.com> - 2013-01-10 14:13 -0800
          Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-10 22:32 +0000
            Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-10 17:49 -0500
              Re: Command line arguments BruceS <bruces42@hotmail.com> - 2013-01-10 16:05 -0700
                Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-10 18:15 -0500
                Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-11 06:54 +0000
                  Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 02:26 -0500
                  Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 09:02 +0000
                    Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 11:17 -0700
                      Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 13:20 -0500
                        Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 13:13 -0700
                      Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:22 +0000
                      Re: Command line arguments Fred K <fred.l.kleinschmidt@gmail.com> - 2013-01-11 14:42 -0800
                        Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 01:22 +0000
                        Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:39 +0000
                          Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:16 +0000
                            Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 09:49 -0800
                      Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-12 04:14 +0000
                  Re: Command line arguments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-13 20:19 +0200
                    Re: Command line arguments JohnF <john@please.see.sig.for.email.com> - 2013-01-14 04:56 +0000
                  Re: Command line arguments Ken Brody <kenbrody@spamcop.net> - 2013-01-22 15:32 -0500
                Re: Command line arguments Ken Brody <kenbrody@spamcop.net> - 2013-01-22 15:25 -0500
            Re: Command line arguments Fred K <fred.l.kleinschmidt@gmail.com> - 2013-01-10 14:49 -0800
            Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 00:11 +0000
            Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-10 21:16 -0500
            Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 21:25 -0600
        Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-10 21:05 -0500
          Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 21:15 -0500
            Re: Command line arguments 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-11 01:36 -0800
              Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 19:33 +0000
                Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 14:57 -0500
                Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 14:26 -0600
                  Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 20:49 +0000
                    Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 18:15 -0600
                      Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:11 +0000
                        Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 01:38 +0000
                        Re: Command line arguments Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-12 14:57 -0800
                          Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-12 18:08 -0500
                          Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-13 00:42 +0000
                            Re: Command line arguments Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-13 12:31 -0800
                        Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-13 04:54 -0600
                          Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-13 12:37 +0000
                  Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-11 15:54 -0500
                    Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 21:16 +0000
                  Re: Command line arguments Greg Martin <greg@softsprocket.com> - 2013-01-11 13:17 -0800
                    Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 22:48 +0000
                Re: Command line arguments gazelle@shell.xmission.com (Kenny McCormack) - 2013-01-11 22:53 +0000
                Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-11 23:46 +0000
                  Re: Command line arguments Robert Wessel <robertwessel2@yahoo.com> - 2013-01-11 18:12 -0600
                  Re: Command line arguments Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-11 19:59 -0500
                  Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 01:32 +0000
                    Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 02:47 +0000
                      Re: Command line arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-12 03:23 +0000
                      Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-11 22:28 -0700
                  Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-11 18:54 -0800
                    Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:42 +0000
                  Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-11 23:18 -0500
                    Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 12:06 +0000
                      Re: Command line arguments James Kuyper <jameskuyper@verizon.net> - 2013-01-12 11:43 -0500
                      Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-12 10:27 -0700
                      Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 10:22 -0800
                        Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 20:26 +0000
                          Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 20:53 +0000
                            Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-12 16:58 -0800
                              Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-13 01:51 +0000
                                Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-13 00:27 -0800
                                  Re: Command line arguments Sjouke Burry <s@b> - 2013-01-14 06:00 +0000
                                    Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-14 21:44 +0000
                      Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-12 16:10 -0500
                        Re: Command line arguments "BartC" <bc@freeuk.com> - 2013-01-12 21:25 +0000
                      Re: Command line arguments pacman@kosh.dhis.org (Alan Curry) - 2013-01-12 22:10 +0000
                        Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 01:30 +0000
                          Re: (OT keyboard input) Keith Thompson <kst-u@mib.org> - 2013-01-12 20:47 -0800
                          Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-13 08:46 +0000
                            Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-13 03:56 -0600
                              Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 12:10 +0000
                                Re: (OT keyboard input) Lew Pitcher <lpitcher@teksavvy.com> - 2013-01-13 11:21 -0500
                                  Re: (OT keyboard input) 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-13 09:43 -0800
                                    Re: (OT keyboard input) "osmium" <r124c4u102@comcast.net> - 2013-01-13 12:09 -0600
                                Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-13 20:34 +0000
                                  Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-13 21:58 +0000
                                    Re: (OT keyboard input) Dr Nick <nospam-4@temporary-address.org.uk> - 2013-01-13 22:26 +0000
                                    Re: (OT keyboard input) Greg Martin <greg@softsprocket.com> - 2013-01-13 14:51 -0800
                                    Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-13 23:47 +0000
                                    Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-14 01:34 +0000
                                      Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-13 23:53 -0500
                                        Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-14 00:26 -0600
                                          Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-14 07:36 -0500
                                            Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-14 13:40 -0600
                                        Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 14:23 +0000
                                      Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 13:36 +0000
                                        Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-14 09:25 -0500
                                        Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-14 21:09 +0000
                                          Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 22:06 +0000
                                            Re: (OT keyboard input) Nobody <nobody@nowhere.com> - 2013-01-15 08:16 +0000
                                              Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-15 11:50 +0000
                                                Re: (OT keyboard input) Keith Thompson <kst-u@mib.org> - 2013-01-15 07:53 -0800
                                                Re: (OT keyboard input) Nobody <nobody@nowhere.com> - 2013-01-15 20:26 +0000
                                            Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-15 21:08 +0000
                                              Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-15 22:19 +0000
                                                Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-15 20:37 -0500
                                                  Re: (OT keyboard input) Robert Wessel <robertwessel2@yahoo.com> - 2013-01-16 02:24 -0600
                                                Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-16 04:28 +0000
                                                  Re: (OT keyboard input) James Kuyper <jameskuyper@verizon.net> - 2013-01-16 06:44 -0500
                                                  Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-16 13:57 +0000
                                                    Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-16 14:32 +0000
                                                      Re: (OT keyboard input) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-17 00:35 +0000
                                            Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-15 23:51 +0000
                                        Re: (OT keyboard input) pacman@kosh.dhis.org (Alan Curry) - 2013-01-14 21:15 +0000
                                          Re: (OT keyboard input) "BartC" <bc@freeuk.com> - 2013-01-14 21:59 +0000
                          Re: (OT keyboard input) Greg Martin <greg@softsprocket.com> - 2013-01-13 10:04 -0800
                          Re: (OT keyboard input) Roberto Waltman <usenet@rwaltman.com> - 2013-01-13 20:09 -0500
        Re: Command line arguments Geoff <geoff@invalid.invalid> - 2013-01-10 23:47 -0800
      Re: Command line arguments Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-13 20:03 +0200
    Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-10 22:30 +0000
    Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 18:12 -0500
      Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-10 18:15 -0500
      Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-11 00:16 +0000
    Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-10 15:46 -0800
    Re: Command line arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2013-01-10 17:58 -0700
    Re: Command line arguments Johann Klammer <klammerj@NOSPAM.a1.net> - 2013-01-11 09:26 +0100
    Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 21:23 -0600
      Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-12 03:45 +0000
      Re: Command line arguments Philip Lantz <prl@canterey.us> - 2013-01-11 20:52 -0800
        Re: Command line arguments Les Cargill <lcargill99@comcast.com> - 2013-01-11 23:21 -0600
      Re: Command line arguments Keith Thompson <kst-u@mib.org> - 2013-01-12 09:52 -0800
    Re: Command line arguments James Dow Allen <jdallen2000@yahoo.com> - 2013-01-13 01:22 -0800
      Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-13 11:11 -0500
        Re: Command line arguments Azazel <azazel@remove.azazel.net> - 2013-01-14 09:26 -0600
          Re: Command line arguments Shao Miller <sha0.miller@gmail.com> - 2013-01-14 17:08 -0500
            Re: Command line arguments glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-14 23:13 +0000
          Re: Command line arguments 88888 Dihedral <dihedral88888@googlemail.com> - 2013-01-14 22:11 -0800

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#29906 — Command line arguments

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 

[toc] | [next] | [standalone]

#29907

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 '*'
*

[toc] | [prev] | [next] | [standalone]

#29945

Since a lot of the discussion is now about modifying the shell's default 
behavior... be aware that *all* other programs expect the shell to do 
globbing, so you'd have to modify them all to do the globbing themselves.

Not realistic.

[toc] | [prev] | [next] | [standalone]

#29952

pu <uselpa.list@gmail.com> wrote:
> Since a lot of the discussion is now about modifying the shell's default 
> behavior... be aware that *all* other programs expect the shell to do 
> globbing, so you'd have to modify them all to do the globbing themselves.
 
> Not realistic.

No, most users expect the shell to do the globbing.
Programs don't care at all.

If a specific users doesn't, then that is perfectly fine.

Also, it is safer as one doesn't have to worry about accidentally
typing

rm -rf *

and deleting too many files.

If you use subdirectories well, then all might be fine.

(Programs that do recursive operation, like rm and cp, do have
to be able to expand directory listings internally.)

I pretty often do something like

cd X*

if I know that there is only one directory (and no file) starting
with X. 

-- glen

[toc] | [prev] | [next] | [standalone]

#29908

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

[toc] | [prev] | [next] | [standalone]

#29909

"Willem" <willem@turtle.stack.nl> wrote in message
news:slrnkeub42.2kpf.willem@turtle.stack.nl...
> 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 

[toc] | [prev] | [next] | [standalone]

#29910

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   .

[toc] | [prev] | [next] | [standalone]

#29911

On 13-01-10 01:34 PM, BartC wrote:
> "Willem" <willem@turtle.stack.nl> wrote in message
> news:slrnkeub42.2kpf.willem@turtle.stack.nl...
>> 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

[toc] | [prev] | [next] | [standalone]

#29913

"Greg Martin" <greg@softsprocket.com> wrote in message
news:_1HHs.63$kp4.24@newsfe09.iad...
> 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  

[toc] | [prev] | [next] | [standalone]

#29915

On Thursday 10 January 2013 17:32, in comp.lang.c, bc@freeuk.com wrote:

> "Greg Martin" <greg@softsprocket.com> wrote in message
> news:_1HHs.63$kp4.24@newsfe09.iad...
>> 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"

[toc] | [prev] | [next] | [standalone]

#29918

On 01/10/2013 03:49 PM, Lew Pitcher wrote:
> On Thursday 10 January 2013 17:32, in comp.lang.c, bc@freeuk.com wrote:
>
>> "Greg Martin" <greg@softsprocket.com> wrote in message
>> news:_1HHs.63$kp4.24@newsfe09.iad...
>>> 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.

Lew beat me to it.  From a terminal (in Linux), type 'echo *', and it 
echos a list of the files in that directory.  Enclose in quotes (as 
suggested elsethread), and type 'echo "*"', and get a single asterix. 
If, as Greg suggested, I type 'set -o noglog', then type 'echo *', I get 
the single asterix.  The globbing is being done by the OS, before your 
program gets run.  Bart, I don't know if noglob works in all shells, but 
that sounds like your best bet for the Linux side, as you say using 
enclosing quotes isn't practical.

> 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

Thanks, Lew.  I may never have a need for noglob, but I didn't know 
about it before.

[toc] | [prev] | [next] | [standalone]

#29921

On Thursday 10 January 2013 18:05, in comp.lang.c, bruces42@hotmail.com
wrote:

> On 01/10/2013 03:49 PM, Lew Pitcher wrote:
[snip]
>> 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?
>
> Thanks, Lew.  I may never have a need for noglob, but I didn't know
> about it before.

You're welcome, BruceS

I can't claim the "-o noglob" option idea as my own, and others also know of
the quoting solution, but thanks for the kudos anyway ;-)

As for my real advice, the OP should read the manpage for the Unix find(1)
command, specifically where it addresses the -name option. find(1) performs
it's own globbing internally, and the manpage makes special note of it

To quote:
  -name pattern
     Base  of  file  name  (the  path  with  the  leading directories
     removed) matches  shell  pattern  pattern.   The  metacharacters
     (`*',  `?',  and `[]') match a `.' at the start of the base name
     (this is a change in findutils-4.2.2; see section STANDARDS CON-
     FORMANCE  below).  To ignore a directory and the files under it,
     use -prune; see an example in  the  description  of  -wholename.
     Braces  are  not  recognised  as being special, despite the fact
     that some shells including Bash  imbue  braces  with  a  special
     meaning  in  shell patterns.  The filename matching is performed
     with the use of the fnmatch(3) library function.   Don't  forget
     to  enclose  the  pattern  in quotes in order to protect it from
     expansion by the shell.

Note that last line in the documentation:
  "Don't  forget to  enclose  the  pattern  in quotes in order to protect it
   from expansion by the shell."

That's how you solve that particular human-factors problem.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#29934

BruceS <bruces42@hotmail.com> wrote:
> <<snip>>  From a terminal (in Linux), type 'echo *', and it 
> echos a list of the files in that directory.  Enclose in quotes (as 
> suggested elsethread), and type 'echo "*"', and get a single asterix. 

No longer a C question, per se, but bash's behavior (at least on
my slackware 14.0 box) is a bit more complicated than suggested above.
echo *     echoes a list of all files as stated
echo t*.c  echoes test.c because that's the only such file in my /home
echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
So if there are no matches, it reverts to echoing the string rather
than emitting an error like ls would. Is there a more general rule
behind that behavior? I ask because I also have a C program,
in this case evaluating command-line expressions which can be,
say, a*b, and I've never (so far) had any problem. Is that just
lucky because there never happened to be any filename matches?
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#29935

On 1/11/2013 01:54, JohnF wrote:
> BruceS <bruces42@hotmail.com> wrote:
>> <<snip>>  From a terminal (in Linux), type 'echo *', and it
>> echos a list of the files in that directory.  Enclose in quotes (as
>> suggested elsethread), and type 'echo "*"', and get a single asterix.
>
> No longer a C question, per se, but bash's behavior (at least on
> my slackware 14.0 box) is a bit more complicated than suggested above.
> echo *     echoes a list of all files as stated
> echo t*.c  echoes test.c because that's the only such file in my /home
> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
> So if there are no matches, it reverts to echoing the string rather
> than emitting an error like ls would. Is there a more general rule
> behind that behavior? I ask because I also have a C program,
> in this case evaluating command-line expressions which can be,
> say, a*b, and I've never (so far) had any problem. Is that just
> lucky because there never happened to be any filename matches?
>

Well I'm not sure what else makes sense to do, in that situation.  It 
seems that any rule other than "pass what was provided, verbatim" would 
be unnecessarily artificial.  At least with the behaviour you describe, 
a call to 'fopen' can fail and the program can report "File not found: 
a*.c" (for a program expecting a list of filenames as arguments).

-- 
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily,"  -- Richard Harter

[toc] | [prev] | [next] | [standalone]

#29938

JohnF <john@please.see.sig.for.email.com> wrote:
> BruceS <bruces42@hotmail.com> wrote:
>> <<snip>>  From a terminal (in Linux), type 'echo *', and it 
>> echos a list of the files in that directory.  Enclose in quotes (as 
>> suggested elsethread), and type 'echo "*"', and get a single asterix. 
 
> No longer a C question, per se, but bash's behavior (at least on
> my slackware 14.0 box) is a bit more complicated than suggested above.
> echo *     echoes a list of all files as stated
> echo t*.c  echoes test.c because that's the only such file in my /home
> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
> So if there are no matches, it reverts to echoing the string rather
> than emitting an error like ls would. 

Not quite. 

ls gives the error when it tries to find the file a*.c and fails.
echo just prints its argument.

So bash does the same thing in both cases, with different results.

If a file names a*.c actually existed, then it would match a*.c,
and ls would list it.

> Is there a more general rule
> behind that behavior? I ask because I also have a C program,
> in this case evaluating command-line expressions which can be,
> say, a*b, and I've never (so far) had any problem. Is that just
> lucky because there never happened to be any filename matches?

csh and tcsh will say

echo: No match.

(or whatever program you tried to run)

-- glen

[toc] | [prev] | [next] | [standalone]

#29948

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> JohnF <john@please.see.sig.for.email.com> wrote:
>> BruceS <bruces42@hotmail.com> wrote:
>>> <<snip>>  From a terminal (in Linux), type 'echo *', and it 
>>> echos a list of the files in that directory.  Enclose in quotes (as 
>>> suggested elsethread), and type 'echo "*"', and get a single asterix. 
>  
>> No longer a C question, per se, but bash's behavior (at least on
>> my slackware 14.0 box) is a bit more complicated than suggested above.
>> echo *     echoes a list of all files as stated
>> echo t*.c  echoes test.c because that's the only such file in my /home
>> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
>> So if there are no matches, it reverts to echoing the string rather
>> than emitting an error like ls would. 
>
> Not quite. 
>
> ls gives the error when it tries to find the file a*.c and fails.
> echo just prints its argument.
>
> So bash does the same thing in both cases, with different results.
>
> If a file names a*.c actually existed, then it would match a*.c,
> and ls would list it.

Trying this with ls, I was surprised to learn that JohnF's
interpretation is actually correct:

snowball:515$ ls a*.c
/bin/ls: cannot access a*.c: No such file or directory

So 'a*.c' must have actually been passed verbatim to /bin/ls.

>> Is there a more general rule
>> behind that behavior? I ask because I also have a C program,
>> in this case evaluating command-line expressions which can be,
>> say, a*b, and I've never (so far) had any problem. Is that just
>> lucky because there never happened to be any filename matches?
>
> csh and tcsh will say
>
> echo: No match.
>
> (or whatever program you tried to run)
>
> -- glen

[toc] | [prev] | [next] | [standalone]

#29949

On 1/11/2013 13:17, Joe Pfeiffer wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> JohnF <john@please.see.sig.for.email.com> wrote:
>>> BruceS <bruces42@hotmail.com> wrote:
>>>> <<snip>>  From a terminal (in Linux), type 'echo *', and it
>>>> echos a list of the files in that directory.  Enclose in quotes (as
>>>> suggested elsethread), and type 'echo "*"', and get a single asterix.
>>
>>> No longer a C question, per se, but bash's behavior (at least on
>>> my slackware 14.0 box) is a bit more complicated than suggested above.
>>> echo *     echoes a list of all files as stated
>>> echo t*.c  echoes test.c because that's the only such file in my /home
>>> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
>>> So if there are no matches, it reverts to echoing the string rather
>>> than emitting an error like ls would.
>>
>> Not quite.
>>
>> ls gives the error when it tries to find the file a*.c and fails.
>> echo just prints its argument.
>>
>> So bash does the same thing in both cases, with different results.
>>
>> If a file names a*.c actually existed, then it would match a*.c,
>> and ls would list it.
>
> Trying this with ls, I was surprised to learn that JohnF's
> interpretation is actually correct:
>
> snowball:515$ ls a*.c
> /bin/ls: cannot access a*.c: No such file or directory
>
> So 'a*.c' must have actually been passed verbatim to /bin/ls.
>
>>> Is there a more general rule
>>> behind that behavior? I ask because I also have a C program,
>>> in this case evaluating command-line expressions which can be,
>>> say, a*b, and I've never (so far) had any problem. Is that just
>>> lucky because there never happened to be any filename matches?
>>
>> csh and tcsh will say
>>
>> echo: No match.
>>
>> (or whatever program you tried to run)
>>

It actually looks to me like everyone is in agreement about this bit. 
Perhaps there was a misunderstanding.

-- 
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily,"  -- Richard Harter

[toc] | [prev] | [next] | [standalone]

#29959

Shao Miller <sha0.miller@gmail.com> writes:

> On 1/11/2013 13:17, Joe Pfeiffer wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>>> JohnF <john@please.see.sig.for.email.com> wrote:
>>>> BruceS <bruces42@hotmail.com> wrote:
>>>>> <<snip>>  From a terminal (in Linux), type 'echo *', and it
>>>>> echos a list of the files in that directory.  Enclose in quotes (as
>>>>> suggested elsethread), and type 'echo "*"', and get a single asterix.
>>>
>>>> No longer a C question, per se, but bash's behavior (at least on
>>>> my slackware 14.0 box) is a bit more complicated than suggested above.
>>>> echo *     echoes a list of all files as stated
>>>> echo t*.c  echoes test.c because that's the only such file in my /home
>>>> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
>>>> So if there are no matches, it reverts to echoing the string rather
>>>> than emitting an error like ls would.
>>>
>>> Not quite.
>>>
>>> ls gives the error when it tries to find the file a*.c and fails.
>>> echo just prints its argument.
>>>
>>> So bash does the same thing in both cases, with different results.
>>>
>>> If a file names a*.c actually existed, then it would match a*.c,
>>> and ls would list it.
>>
>> Trying this with ls, I was surprised to learn that JohnF's
>> interpretation is actually correct:
>>
>> snowball:515$ ls a*.c
>> /bin/ls: cannot access a*.c: No such file or directory
>>
>> So 'a*.c' must have actually been passed verbatim to /bin/ls.
>>
>>>> Is there a more general rule
>>>> behind that behavior? I ask because I also have a C program,
>>>> in this case evaluating command-line expressions which can be,
>>>> say, a*b, and I've never (so far) had any problem. Is that just
>>>> lucky because there never happened to be any filename matches?
>>>
>>> csh and tcsh will say
>>>
>>> echo: No match.
>>>
>>> (or whatever program you tried to run)
>>>
>
> It actually looks to me like everyone is in agreement about this
> bit. Perhaps there was a misunderstanding.

Rereading Glen's post, I think I misunderstood him.  My apologies.

[toc] | [prev] | [next] | [standalone]

#29955

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> JohnF <john@please.see.sig.for.email.com> wrote:

(snip)
>>> No longer a C question, per se, but bash's behavior (at least on
>>> my slackware 14.0 box) is a bit more complicated than suggested above.
>>> echo *     echoes a list of all files as stated
>>> echo t*.c  echoes test.c because that's the only such file in my /home
>>> echo a*.c  echoes a*.c   apparently because there are no a*.c files at all
>>> So if there are no matches, it reverts to echoing the string rather
>>> than emitting an error like ls would. 

>> Not quite. 

>> ls gives the error when it tries to find the file a*.c and fails.
>> echo just prints its argument.

>> So bash does the same thing in both cases, with different results.

>> If a file names a*.c actually existed, then it would match a*.c,
>> and ls would list it.

> Trying this with ls, I was surprised to learn that JohnF's
> interpretation is actually correct:
> 
> snowball:515$ ls a*.c
> /bin/ls: cannot access a*.c: No such file or directory
 
> So 'a*.c' must have actually been passed verbatim to /bin/ls.

Yes. 

I was surprised, too, as I usually use tcsh. 

But it isn't that bash treats echo and ls differently.
(Which it could, as echo is an internal bash command, and
ls isn't.) 
 
>>> Is there a more general rule behind that behavior? 

Shells like csh and tcsh will just give the error message
and not run the command (internal or external).

Bash passes the unexpanded form to the command, which may or
may not be what one wants, and may or may not generate a
message.

I suppose it is convenient with find, as one can say

cd /
find . -name *.c

as it would be rare to have any .c files in /, it would work.
Though I am pretty used to typing \*.c for find.

On the other hand, 

vi *.c

would start editing *.c.

-- glen

[toc] | [prev] | [next] | [standalone]

#29971

On Friday, January 11, 2013 10:17:42 AM UTC-8, Joe Pfeiffer wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > JohnF <john@please.see.sig.for.email.com> wrote: >> BruceS <bruces42@hotmail.com> wrote: >>> <<snip>> From a terminal (in Linux), type 'echo *', and it >>> echos a list of the files in that directory. Enclose in quotes (as >>> suggested elsethread), and type 'echo "*"', and get a single asterix. > >> No longer a C question, per se, but bash's behavior (at least on >> my slackware 14.0 box) is a bit more complicated than suggested above. >> echo * echoes a list of all files as stated >> echo t*.c echoes test.c because that's the only such file in my /home >> echo a*.c echoes a*.c apparently because there are no a*.c files at all >> So if there are no matches, it reverts to echoing the string rather >> than emitting an error like ls would. > > Not quite. > > ls gives the error when it tries to find the file a*.c and fails. > echo just prints its argument. > > So bash does the same thing in both cases, with different results. > > If a file names a*.c actually existed, then it would match a*.c, > and ls would list it. Trying this with ls, I was surprised to learn that JohnF's interpretation is actually correct: snowball:515$ ls a*.c /bin/ls: cannot access a*.c: No such file or directory So 'a*.c' must have actually been passed verbatim to /bin/ls. >> Is there a more general rule >> behind that behavior? I ask because I also have a C program, >> in this case evaluating command-line expressions which can be, >> say, a*b, and I've never (so far) had any problem. Is that just >> lucky because there never happened to be any filename matches? > > csh and tcsh will say > > echo: No match. > > (or whatever program you tried to run) > > -- glen


When there is no wild-card match, the Unix shell passes the actual as-typed string or strings as arguments to the program.
Therefore "  ls *.a *.b" will pass "*.a" and "*.b" as the arguments to ls
if there are no files with .a or .b extensions.

However, if there is at least one match, then the shell passes
the match(es) as argument(s).
-- 
Fred K

[toc] | [prev] | [next] | [standalone]

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web