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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#29983

Fred K <fred.l.kleinschmidt@gmail.com> wrote:

(snip)
 
> When there is no wild-card match, the Unix shell passes the 
> actual as-typed string or strings as arguments to the program.

If by unix shell you mean the Bourne shell (sh) or its descendant,
then yes. csh and tcsh don't do that.

> 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).

[gah@localhost ~/tmp]$ ls *.a
ls: No match.
[gah@localhost ~/tmp]$ 

-- glen

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

#29986

Fred K <fred.l.kleinschmidt@gmail.com> writes:

> When there is no wild-card match, the Unix shell passes the actual
> as-typed string or strings as arguments to the program.

This has been stated more than once but it varies from between shells
and it is even configurable in some.  The term "the Unix shell" is
ambiguous, but what you describe is the default behaviour of the default
shell in many Unix systems.  It's just neither universal nor fixed.

<snip>
-- 
Ben.

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

#29994

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Fred K <fred.l.kleinschmidt@gmail.com> writes:
 
>> When there is no wild-card match, the Unix shell passes the actual
>> as-typed string or strings as arguments to the program.
 
> This has been stated more than once but it varies from between shells
> and it is even configurable in some.  The term "the Unix shell" is

Well, I suppose "the unix shell" does have some meaning, which would
be the (original) Bourne shell, back from when there was only one.

> ambiguous, but what you describe is the default behaviour of the default
> shell in many Unix systems.  It's just neither universal nor fixed.

But yes, now there are plenty of shells to go around.

-- glen

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

#30021

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Fred K <fred.l.kleinschmidt@gmail.com> writes:
>  
>>> When there is no wild-card match, the Unix shell passes the actual
>>> as-typed string or strings as arguments to the program.
>  
>> This has been stated more than once but it varies from between shells
>> and it is even configurable in some.  The term "the Unix shell" is
>
> Well, I suppose "the unix shell" does have some meaning, which would
> be the (original) Bourne shell, back from when there was only one.

The POSIX standard defines a set of functionality for "the" shell.
Bourne-derived shells generally attempt to conform to that standard,
while adding their own extensions.  csh and tcsh don't.

And /bin/sh (which can be the Bourne shell or someting else) has a
special status; it's what system() uses to process its string argument.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#30000

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> 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.

Yeah, that was exactly my thinking about the observed behavior
of echo and ls in the several situations enumerated above:
the shell's making a few more choices than you might naively
expect. If it's going to expand a*.c and there are no matching
files, then I'd naively expect to see an empty string,
i.e., I'd expect echo a*.c to emit a blank line. Or if it's going
to "pass verbatim" like you said, then it should always do that,
whether or not matching files exist. As it stands, the behavior is
somewhat unpredictable, depending on the contents of your pwd.
But I'm sure the people who wrote it that way have their reasons
why this is usually the most desireable behavior, if not the most
rational behavior.

>>> 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)
>
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#30071

JohnF <john@please.see.sig.for.email.com> writes:

> 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?

As always, man bash(1). When there, /nullglob and /shopt.

e.g.:
"""
$ echo *.xxx
*.xxx
$ shopt -s nullglob
$ echo *.xxx

"""

Phil
-- 
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.

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

#30107

Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> JohnF <john@please.see.sig.for.email.com> writes:
>> 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?
> 
> As always, man bash(1). When there, /nullglob and /shopt.
> e.g.:
> """
> $ echo *.xxx
> *.xxx
> $ shopt -s nullglob
> $ echo *.xxx
> 
> """
> Phil

Thanks for the info, Phil. Yeah, that answers my questions,
and failglob gives yet another option (similar to ls).
Wasn't aware of shopt, and hadn't read bash's long manpage,
but knowing where to look makes reading it more man(ageable).
   Still doesn't completely simplify C programming, however,
where I'm often picking up command-line args, and sometimes
passing them on to popen() in a constructed command string.
Might still be hard to strictly control any unexpected
globbing behavior, e.g., on strings containing an * that's
not intended as a (wildcard) file specification at all.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

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

#30519

On 1/11/2013 1:54 AM, 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?

"ls" gives an error, because it gets passed the argument "a*.c", and there 
is no such file by that name.  Why should "echo" give an error when passed 
the argument "a*.c"?

The shell is being consistent -- if no file matches the wildcard, then that 
raw wildcard is passed.  What the program chooses to do with that argument 
is up to that program.

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

#30518

On 1/10/2013 6:05 PM, BruceS wrote:
> On 01/10/2013 03:49 PM, Lew Pitcher wrote:
[...]
>>>> 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
[...]
> 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.

Just note that that will affect *everything* for that shell.  What happens 
when the user complains that he can no longer do things like "ls -l *.txt"?

>> 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]

#29916

On Thursday, January 10, 2013 2:32:23 PM UTC-8, Bart 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. -- 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

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

#29925

BartC <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.

No program do that. Now you know why.

> 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.

There are cases where files can be lost due to misusing file expansion.

Users of some other systems sometimes try

mv abc.* xyz.*

If there are two files starting with abc., the first will replace
the second. Don't do that.

Now, there is another form of mv that takes a list of files and one
directory. It will only work if the last one in the list is a directory,
though.
 
>> 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.

No programs expect the expansion, users do.

If you type

rm *.c

the rm command gets a list of files, which it deletes. With noglob, it
will (try to) delete a file named *.c, most likely one doesn't exist.

Normally, you either quote the file, or list of files, that you don't
want expanded, or escape with \ the * or ? you don't want expanded.

rm \*.c

will delete a file named *.c, instead of all .c files.

-- glen

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

#29931

On 01/10/2013 05:32 PM, BartC 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.

Typically, that kind of situation is handled with options: command line
arguments that, by convention, start with a single '-' followed by one
or more single letter option identifiers, or by a "--" followed by an
option name. So, for example, you could write

    myprogram -i *.in -o *.out

or

    myprogram --input *.in --output *.out

This leads to potential problems: it's perfectly feasible to create a
file with a name that looks like a command line option. Some malware
creates files with such names, hoping to cause certain commands to
produce confusing or malignant consequences. However, in practice,
that's generally 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
> 
> 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.

It's not so much the C programs, as the users, that will have problems.
Instead of typing

	wc *.c

the user will have to perform the expansion by hand, replacing *.c with
the complete list of file that *.c would have expanded to. That person
will NOT thank you for choosing noglob.
-- 
James Kuyper

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

#29997

BartC 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.
>


So wrap it with a script.

--
Les Cargill

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

#29929

On 01/10/2013 04:34 PM, 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?)

Yes, because it's trivial to prevent wild card expansion, if you don't
need it, by using double quotes. I use wild card expansions constantly
while working on Unix-like machines, and I've found them extremely
useful. When I was writing code, several decades ago, to run on a DOS
platform using the Command Line Interpreter, I had to use DOS utilities
to emulate the same behavior that occurred automatically under unix
shells. I found it quite annoying.
-- 
James Kuyper

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

#29930

On 1/10/2013 21:05, James Kuyper wrote:
> On 01/10/2013 04:34 PM, 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?)
>
> Yes, because it's trivial to prevent wild card expansion, if you don't
> need it, by using double quotes. I use wild card expansions constantly
> while working on Unix-like machines, and I've found them extremely
> useful. When I was writing code, several decades ago, to run on a DOS
> platform using the Command Line Interpreter, I had to use DOS utilities
> to emulate the same behavior that occurred automatically under unix
> shells. I found it quite annoying.
>

And that's why, if you compile a POSIX- or UNIX-style program for 
Windows, it'll usually include a startup routine to reproduce this 
behaviour, since you can invoke your POSIX- or UNIX-style program from a 
CLI/shell that _doesn't_ do this command-line expansion before passing 
it on to the program.

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

Cheerily,"  -- Richard Harter

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

#29939

Shao Miller於 2013年1月11日星期五UTC+8上午10時15分52秒寫道：
> On 1/10/2013 21:05, James Kuyper wrote:
> 
> > On 01/10/2013 04:34 PM, 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?)
> 
> >
> 
> > Yes, because it's trivial to prevent wild card expansion, if you don't
> 
> > need it, by using double quotes. I use wild card expansions constantly
> 
> > while working on Unix-like machines, and I've found them extremely
> 
> > useful. When I was writing code, several decades ago, to run on a DOS
> 
> > platform using the Command Line Interpreter, I had to use DOS utilities
> 
> > to emulate the same behavior that occurred automatically under unix
> 
> > shells. I found it quite annoying.
> 
> >
> 
> 
> 
> And that's why, if you compile a POSIX- or UNIX-style program for 
> 
> Windows, it'll usually include a startup routine to reproduce this 
> 
> behaviour, since you can invoke your POSIX- or UNIX-style program from a 
> 
> CLI/shell that _doesn't_ do this command-line expansion before passing 
> 
> it on to the program.
> 
> 
> 
> -- 
> 
> "Thank you for the kind words; those are the kind of words I like to hear.
> 
> 
> 
> Cheerily,"  -- Richard Harter
Well, you are reminding me the dir function 
from the M$ in the 1990 that refused to 
do nested diretory search under 1M.

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

#29957

88888 Dihedral <dihedral88888@googlemail.com> wrote:

(snip)

> Well, you are reminding me the dir function 
> from the M$ in the 1990 that refused to 
> do nested diretory search under 1M.

The way command line expansion is done in current windows is
still surprising to unix users.

Unix ls, with shell globbing, will show the contents of the
directories in the expanded directory list.

dir *

on windows will show the contents of the current directory.

cd *

doesn't work right on Windows (even if there is only one directory)
but it does with unix shells.

And I still remember my first MSDOS system, version 3.2, where the
RENAME command wouldn't move files to a different directory
(like unix mv) but the C library rename() function would.

(The Windows MOVE command is much more recent.)

-- glen

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

#29958

On 1/11/2013 14:33, glen herrmannsfeldt wrote:
>
> And I still remember my first MSDOS system, version 3.2, where the
> RENAME command wouldn't move files to a different directory
> (like unix mv) but the C library rename() function would.
>
> (The Windows MOVE command is much more recent.)

While Standard C doesn't talk about "what's in a name" for the 'rename' 
function, the DOS RENAME command does just what it says and nothing 
more. :)  I've always enjoyed this because if I'm far away, I don't have 
to specify the long path twice:

   ren i\m\way\up\here\file.ext newname.ext

-- 
- 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]

#29961

On Fri, 11 Jan 2013 19:33:24 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>88888 Dihedral <dihedral88888@googlemail.com> wrote:
>
>(snip)
>
>> Well, you are reminding me the dir function 
>> from the M$ in the 1990 that refused to 
>> do nested diretory search under 1M.
>
>The way command line expansion is done in current windows is
>still surprising to unix users.
>
>Unix ls, with shell globbing, will show the contents of the
>directories in the expanded directory list.
>
>dir *
>
>on windows will show the contents of the current directory.
>
>cd *
>
>doesn't work right on Windows (even if there is only one directory)
>but it does with unix shells.


True, Windows requires you to enter at least one letter.


>And I still remember my first MSDOS system, version 3.2, where the
>RENAME command wouldn't move files to a different directory
>(like unix mv) but the C library rename() function would.
>
>(The Windows MOVE command is much more recent.)


I don't think anyone is arguing that globbing is not helpful - in many
cases it is, but it's the wrong thing sometimes, and *nix has no good
way for a program to bypass it (and turning it off in the shell
doesn't count).  You can't even access the raw command line to roll
your own if you wanted.

Of course some OS/library support for rolling your own would be nice
too at that point.

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

#29962

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip on unix and Windows command line globbing)

> I don't think anyone is arguing that globbing is not helpful - in many
> cases it is, but it's the wrong thing sometimes, and *nix has no good
> way for a program to bypass it (and turning it off in the shell
> doesn't count).  You can't even access the raw command line to roll
> your own if you wanted.

Seems to me that if you could it would be shell specific.

I wonder if the alias feature of any shell lets you get the raw
command line, quote it, then pass it to a program.

(Bash alias is somewhat different from csh alias.)
 
> Of course some OS/library support for rolling your own would be nice
> too at that point.

Other OS that process the command line in strange ways do, but then
you would be pretty stuck without it.

VMS does much processing on the command line before passing it
to usual commands, and so does CMS.

I suppose a shell could set an ENV variable for the program
to extract.

-- glen

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

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

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

csiph-web