Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #29906 > unrolled thread
| Started by | "BartC" <bc@freeuk.com> |
|---|---|
| First post | 2013-01-10 20:58 +0000 |
| Last post | 2013-01-14 22:11 -0800 |
| Articles | 20 on this page of 139 — 33 participants |
Back to article view | Back to comp.lang.c
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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-11 18:15 -0600 |
| Message-ID | <3ma1f8l39lr3hl4qf868uigduho0aff38d@4ax.com> |
| In reply to | #29962 |
On Fri, 11 Jan 2013 20:49:48 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >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.) While it might be difficult to do at this late date, requiring a shell to support that wouldn't be a big deal.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-12 01:11 +0000 |
| Message-ID | <0.25ef40eb7aa3e397050d.20130112011119GMT.87ip73p5mw.fsf@bsb.me.uk> |
| In reply to | #29977 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Fri, 11 Jan 2013 20:49:48 +0000 (UTC), glen herrmannsfeldt > <gah@ugcs.caltech.edu> wrote: > >>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). Shells do all sorts of special processing before executing a program. Are you making a special case for file globing, or would you like a program to be able to "reach out" and bypass all or any of the others (IO redirection, parameter expansion, command substitution, the various quotes and word splitting, and so on)? >>> 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.) > > > While it might be difficult to do at this late date, requiring a shell > to support that wouldn't be a big deal. You'd have to decide what constitutes the raw command. If you say it's just what was typed, a program would need a complex parser just to work out what it's first argument is! If you mean the command just before file globing is done, then I'd ask again what makes globing the special case? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-01-12 01:38 +0000 |
| Message-ID | <kcqerj$9nt$1@speranza.aioe.org> |
| In reply to | #29980 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: (snip, someone wrote) >>>> 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). > Shells do all sorts of special processing before executing a program. > Are you making a special case for file globing, or would you like a > program to be able to "reach out" and bypass all or any of the others > (IO redirection, parameter expansion, command substitution, the various > quotes and word splitting, and so on)? Well, with many shells I can type !! and run the previous command again. I certainly don't expect the program to see the !! and know what the previous arguments were. Even more, I can type ls !* So, some processing has to be done before the program is run. >>>> You can't even access the raw command line to roll >>>> your own if you wanted. (snip) >> While it might be difficult to do at this late date, requiring a shell >> to support that wouldn't be a big deal. > You'd have to decide what constitutes the raw command. If you say it's > just what was typed, a program would need a complex parser just to work > out what it's first argument is! If you mean the command just before > file globing is done, then I'd ask again what makes globing the special > case? Yes, one of the fun things about unix are programs that recognize the name that they are called with and do things differently. On my system, gzip, gunzip, and gzcat are all the same program. With either a hard or symbolic link, argv[0] is the name actually types, but aliases are replaced before argv[0] is generated. Some (not unix) command line parsers upper case the whole line before processing it. Many programs need the line in the original case. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-01-12 14:57 -0800 |
| Message-ID | <kfntxqm9fib.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #29980 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [snip] If you say it's just what was typed, a program would need a
> complex parser just to work out what it's first argument is! [snip]
^^^^
Oh no! Not you too.... :/
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-12 18:08 -0500 |
| Message-ID | <kcsqcl$aca$1@dont-email.me> |
| In reply to | #30038 |
On 1/12/2013 17:57, Tim Rentsch wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> [snip] If you say it's just what was typed, a program would need a >> complex parser just to work out what it's first argument is! [snip] > ^^^^ > > Oh no! Not you too.... :/ > I read the same text, and had precisely the same exclamation. There is an article about some history of "it's" versus "its" which helps me to feel a little looser about it, these days. I don't know how authoritative it should be considered. :) http://www.word-detective.com/back-d.html#its -- - 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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-13 00:42 +0000 |
| Message-ID | <0.efd0a688114c184c099a.20130113004238GMT.87r4lp7w1t.fsf@bsb.me.uk> |
| In reply to | #30038 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> [snip] If you say it's just what was typed, a program would need a >> complex parser just to work out what it's first argument is! [snip] > ^^^^ > Oh no! Not you too.... :/ Me too what? The existence of typos in my posts can't be news -- I must have just about the highest typo rate of anyone here! If you meant to imply that a typo indicates a lack of knowledge, then I must retort "oh no, not you too?" because I've got very used to that particular canard over the years! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2013-01-13 12:31 -0800 |
| Message-ID | <kfnlibwakpl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #30044 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> [snip] If you say it's just what was typed, a program would need a >>> complex parser just to work out what it's first argument is! [snip] >> ^^^^ >> Oh no! Not you too.... :/ > > Me too what? The existence of typos in my posts can't be news -- > I must have just about the highest typo rate of anyone here! > > If you meant to imply that a typo indicates a lack of knowledge, > then I must retort "oh no, not you too?" because I've got very > used to that particular canard over the years! I'm sorry, what I was trying to say came out wrongly. What I meant was another person writing a possessive "its" with an apostrophe. My comment wasn't meant to be directed specifically at you, or about what the cause might be -- just the result. If it came across differently, I apologize.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-13 04:54 -0600 |
| Message-ID | <i715f8d04gg21rtf3v5s76oru89ba4ji1t@4ax.com> |
| In reply to | #29980 |
On Sat, 12 Jan 2013 01:11:19 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Fri, 11 Jan 2013 20:49:48 +0000 (UTC), glen herrmannsfeldt
>> <gah@ugcs.caltech.edu> wrote:
>>
>>>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).
>
>Shells do all sorts of special processing before executing a program.
>Are you making a special case for file globing, or would you like a
>program to be able to "reach out" and bypass all or any of the others
>(IO redirection, parameter expansion, command substitution, the various
>quotes and word splitting, and so on)?
>
>>>> 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.)
>>
>>
>> While it might be difficult to do at this late date, requiring a shell
>> to support that wouldn't be a big deal.
>
>You'd have to decide what constitutes the raw command. If you say it's
>just what was typed, a program would need a complex parser just to work
>out what it's first argument is! If you mean the command just before
>file globing is done, then I'd ask again what makes globing the special
>case?
Not unreasonable questions. I'd say that anything past whatever
specified the program to be executed and the end of the command being
passed to that program, after doing any user specified processing,
would be the "raw" input. Thus you'd not pass the stuff on the other
side of a pipe, for example, or the text from before a command
substitution ($()) was executed.
Now I might quibble out the syntax of some of those, but that's a
relatively minor complaint*. It's not that I object to globbing, it's
that I think it's something I'd like to ask for, and ask for in
specific places (IOW, I'd be happy to say "cl $(*.c)" if I wanted to
compile all C program in the directory). IMO, the automatic globbing
is genuinely useful in a small number of places, in many places being
able to specify several inputs via a wild hard is occasionally handy
but would be a complete non-issue to require explicit specification
(because the single file name case is far more common), and a real
PITA in others (let's just consider ls), to the point of making some
things flat out impossible. The mistake is that catering for the
small number of cases has messed up other stuff, when the small number
of cases could have been better handled by providing those
applications a globthisstring() function.
Fundamentally, the shell has no idea what in a command might be a
filename, and taking the approach that anything that looks like it
might be a wild-carded filename should be treated as such is, IMO,
rather silly. Something that was hacked in without enough
consideration back in the dark ages sometime, and something were now
stuck with. And has been pointed out in this thread, the way shells
handle edge conditions (like a wildcard specification not matching any
files) varies between shells.
Flip the question around. Why is globbing so special that it alone
doesn't require a special syntax to invoke? Why shouldn't the shell
interpret "echo ls" as me wanting to use the output of ls as the
parameter to echo? Why do I have to say "echo $(ls)" instead?
Of course all the escapes imply special handling if you wanted to pass
them in on a command line as-is, but they're somewhat more clearly
escapes. Obviously the line is a bit fuzzy.
But, it is what it is, and is unlikely to change. Which does not, of
course, prevent me form considering it a mistake.
Nor is messed up command line handling limited to *nix. Plenty of
places have messed it up even worse. Someone mentioned CMS, I think,
where I've spent a fair bit of my life. I don't know what blithering
moron thought that breaking everything into eight character chunks was
a good idea, but I've still got to deal with it. Somewhat oddly,
MS-DOS/Windows style handling of the command line scores somewhat
better in terms of "reasonable behavior", mainly because they never
tried to get clever, and avoided a bunch of opportunities for doing
silly stuff. Of course the lame (normal) Windows shell is a PITA,
since it's so simplistic that it interferes with trying to get work
done.
*But if you want an example, I'd say that brace expansion is done
poorly, as the string you're applying it too is not well delimited.
Rather than "A-{1,2,3}-B" it should be something like "[A-{1,2,3}-B]"
(intended to be an example, the square brackets are overloaded
already).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-01-13 12:37 +0000 |
| Message-ID | <kcu9r3$j27$1@speranza.aioe.org> |
| In reply to | #30061 |
Robert Wessel <robertwessel2@yahoo.com> wrote: (snip) >>You'd have to decide what constitutes the raw command. If you say it's >>just what was typed, a program would need a complex parser just to work >>out what it's first argument is! If you mean the command just before >>file globing is done, then I'd ask again what makes globing the special >>case? > Not unreasonable questions. I'd say that anything past whatever > specified the program to be executed and the end of the command being > passed to that program, after doing any user specified processing, > would be the "raw" input. Thus you'd not pass the stuff on the other > side of a pipe, for example, or the text from before a command > substitution ($()) was executed. > Now I might quibble out the syntax of some of those, but that's a > relatively minor complaint*. It's not that I object to globbing, it's > that I think it's something I'd like to ask for, and ask for in > specific places (IOW, I'd be happy to say "cl $(*.c)" if I wanted to > compile all C program in the directory). IMO, the automatic globbing > is genuinely useful in a small number of places, in many places being > able to specify several inputs via a wild hard is occasionally handy > but would be a complete non-issue to require explicit specification > (because the single file name case is far more common), and a real > PITA in others (let's just consider ls), to the point of making some > things flat out impossible. The mistake is that catering for the > small number of cases has messed up other stuff, when the small number > of cases could have been better handled by providing those > applications a globthisstring() function. It works well with most unix commands, partly because they were designed to work with it. The unix ls command, for example, gives the files inside the specified directory, unless -d is specified. There are a few places where it is less convenient than it could otherwise be, especially for those previously using other systems. There is no standard unix command to do the equivalent of the VMS or MS-DOS RENAME command with wild cards. Consider: RENAME abc.* def.* and compare to the result of typing mv abc.* def.* in unix. Another case that fails is the unix dd commmand. dd if=*.c of=xyz will fail even if there is only one *.c file in the directory. > Fundamentally, the shell has no idea what in a command might be a > filename, and taking the approach that anything that looks like it > might be a wild-carded filename should be treated as such is, IMO, > rather silly. Something that was hacked in without enough > consideration back in the dark ages sometime, and something were now > stuck with. And has been pointed out in this thread, the way shells > handle edge conditions (like a wildcard specification not matching any > files) varies between shells. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2013-01-11 15:54 -0500 |
| Message-ID | <kcpu73$rnf$1@dont-email.me> |
| In reply to | #29961 |
On 1/11/2013 15:26, Robert Wessel wrote: > 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. > > Continuing this bit of off-topic: I don't know what makes you say that. In Windows XP, 'cd <wildcard_pattern>' will change directory into the first matching directory. It so happens that the first matching directory for any wildcard sequence that has no non-wildcard characters is '.'; same as with 'dir *' (without additional switches). '..' also matches, but not before '.'. -- - 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]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-01-11 21:16 +0000 |
| Message-ID | <kcpvfn$8h8$1@speranza.aioe.org> |
| In reply to | #29963 |
Shao Miller <sha0.miller@gmail.com> wrote: (snip, someone wrote) >> True, Windows requires you to enter at least one letter. > Continuing this bit of off-topic: I don't know what makes you say that. > In Windows XP, 'cd <wildcard_pattern>' will change directory into the > first matching directory. It so happens that the first matching > directory for any wildcard sequence that has no non-wildcard characters > is '.'; same as with 'dir *' (without additional switches). '..' also > matches, but not before '.'. This is a little complicated by the way windows CD works. Among other things, you can CD to a directory name with spaces without quoting the name, as you would for most other commands. It does seem that CD . .. does nothing, and generates no error message. (I don't have a directory named ". ..") CD . .. Q (when Q is the only subdirectory) fails with an error message. But yes, if more than one matches the pattern, it does change to the first one with no message. (Unlike unix shells, where cd complains if there is more than one.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2013-01-11 13:17 -0800 |
| Message-ID | <Hj%Hs.51710$pV4.16474@newsfe21.iad> |
| In reply to | #29961 |
On 13-01-11 12:26 PM, Robert Wessel wrote: > 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. > It seems to me that placing quotes around the argument *is* a good way of handling it. Any program run from a command line and requiring arguments will have to be specified and given that unix users are inclined to read man pages and to ask a program itself for --help, it is a simple thing to say "if you wish to use -f with wildcards, and don't want the shell expansion, surround the argument with quotes". However, _most_ unix users will know this already.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2013-01-11 22:48 +0000 |
| Message-ID | <kcq4sb$l4n$1@speranza.aioe.org> |
| In reply to | #29967 |
Greg Martin <greg@softsprocket.com> wrote: (snip on quoting, globbing, and otherwise command line processing) > It seems to me that placing quotes around the argument *is* a good way > of handling it. Any program run from a command line and requiring > arguments will have to be specified and given that unix users are > inclined to read man pages and to ask a program itself for --help, it is > a simple thing to say "if you wish to use -f with wildcards, and don't > want the shell expansion, surround the argument with quotes". However, > _most_ unix users will know this already. I wonder how many users of Apple OS X have never opened a command window, and have no idea about globbing and quoting. Even more, Mac users more than other systems like putting spaces in file names, which require escaping or quoting even without globbing. -- glen
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2013-01-11 22:53 +0000 |
| Message-ID | <kcq559$r26$1@news.xmission.com> |
| In reply to | #29957 |
In article <kcppe4$orb$1@speranza.aioe.org>, 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. And vice versa... -- Those on the right constantly remind us that America is not a democracy; now they claim that Obama is a threat to democracy.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-11 23:46 +0000 |
| Message-ID | <gw1Is.680$lO4.445@fx15.fr7> |
| In reply to | #29957 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:kcppe4$orb$1@speranza.aioe.org... > The way command line expansion is done in current windows is > still surprising to unix users. The most flexible approach would have been to supply a raw, unprocessed command line to a C program. Then it would work exactly the same way as every subsequent line of input. With a library function to chop it up into parameters, and perhaps expand them, if that is desired. In fact WinMain() works exactly like that (apart from having such a function as I suggested). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2013-01-11 18:12 -0600 |
| Message-ID | <8ha1f8tnfoeq5s2jbc84vaqeotnsql5crg@4ax.com> |
| In reply to | #29975 |
On Fri, 11 Jan 2013 23:46:28 -0000, "BartC" <bc@freeuk.com> wrote: >"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >news:kcppe4$orb$1@speranza.aioe.org... > >> The way command line expansion is done in current windows is >> still surprising to unix users. > >The most flexible approach would have been to supply a raw, unprocessed >command line to a C program. Then it would work exactly the same way as >every subsequent line of input. > >With a library function to chop it up into parameters, and perhaps expand >them, if that is desired. > >In fact WinMain() works exactly like that (apart from having such a function >as I suggested). GetCommandLineW(). Although this being Windows, there's no option for globbing.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lpitcher@teksavvy.com> |
|---|---|
| Date | 2013-01-11 19:59 -0500 |
| Message-ID | <cA2Is.23054$fh5.1227@newsfe26.iad> |
| In reply to | #29975 |
On Friday 11 January 2013 18:46, in comp.lang.c, bc@freeuk.com wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:kcppe4$orb$1@speranza.aioe.org...
>
>> The way command line expansion is done in current windows is
>> still surprising to unix users.
>
> The most flexible approach would have been to supply a raw, unprocessed
> command line to a C program. Then it would work exactly the same way as
> every subsequent line of input.
Perhaps, but then the C program would have to do it's own main() argument
parsing. On Windows (at least through COMMAND.COM and CMD.EXE) and Unix
(through whichever shell you choose), the end-user enters one or more lines
of text, and it is the /command parser/ (the shell or CMD) that breaks the
text up into programnames and arguments to main().
For instance, on my Unixish box, I type the following three lines
/bin/echo \
my name is \
lew
and the command interpreter assembles that into an invocation of
the /bin/echo program with
argc == 5
argv[0] -> "/bin/echo",
argv[1] -> "my",
argv[2] -> "name",
argv[3] -> "is",
argv[4] -> "lew", &
argv[5] == NULL
Obviously, for the echo program to get individual arguments, the invoker
(the commandline interpreter) must break up the "raw unprocecssed command
line".
Another example, on my Unixish box, I type the following one line
/bin/echo my name is lew ; /bin/ls
Again, the command interpreter must intervene; the ";" and all that follows
are not part of the /bin/echo argument list, and should not be passed
to /bin/echo. Again, the environment must break up the "raw unprocessed
command line" into something a little more sensible.
Finally, in a Unixish C program (C + POSIX), I code
execlp("/bin/echo","echo","my","name","is","lew",NULL);
and the /bin/echo program again gets the same arguments as my first example.
Here, there is NO command line, not even a "raw unprocessed command line"
to provide to the C program.
HTH
--
Lew Pitcher
"In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-12 01:32 +0000 |
| Message-ID | <0.511e5c58ec135e522e0c.20130112013227GMT.87d2xbp4no.fsf@bsb.me.uk> |
| In reply to | #29975 |
"BartC" <bc@freeuk.com> writes: > "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message > news:kcppe4$orb$1@speranza.aioe.org... > >> The way command line expansion is done in current windows is >> still surprising to unix users. > > The most flexible approach would have been to supply a raw, > unprocessed command line to a C program. Then it would work exactly > the same way as every subsequent line of input. What does each command here see as it's raw unprocessed command line? ls -lt $(find . -name data\*) | head -$1 >>out*.log <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2013-01-12 02:47 +0000 |
| Message-ID | <ba4Is.1867$xE7.773@fx04.fr7> |
| In reply to | #29984 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:0.511e5c58ec135e522e0c.20130112013227GMT.87d2xbp4no.fsf@bsb.me.uk... > "BartC" <bc@freeuk.com> writes: > >> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >> news:kcppe4$orb$1@speranza.aioe.org... >> >>> The way command line expansion is done in current windows is >>> still surprising to unix users. >> >> The most flexible approach would have been to supply a raw, >> unprocessed command line to a C program. Then it would work exactly >> the same way as every subsequent line of input. > > What does each command here see as it's raw unprocessed command line? > > ls -lt $(find . -name data\*) | head -$1 >>out*.log On Windows, characters such as |, < and > have special meaning meaning to the 'shell', so the first command would see: -lt $(find . -name data\*) and the next -$1, which I guess has special meaning in Unix, perhaps like %1 in Windows BAT files. But this is starting to get into scripting now. A few escapes are acceptable (I was going to say inescapable), and sometimes there is nothing the invoked program can do with them anyway. However, to add "*" to the end of \windows\system32\, and turn that one parameter, into 2745 parameters, is something that is in a class of its own. (And imagine that all you'd intended doing with that parameter was to write it out again as a part of an argument to system(). Or perhaps changing a *.c spec to a *.o one, which suddenly becomes a bit more difficult.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2013-01-12 03:23 +0000 |
| Message-ID | <0.862061f1368f6fc76313.20130112032305GMT.87txqnnkyu.fsf@bsb.me.uk> |
| In reply to | #29991 |
"BartC" <bc@freeuk.com> writes: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:0.511e5c58ec135e522e0c.20130112013227GMT.87d2xbp4no.fsf@bsb.me.uk... >> "BartC" <bc@freeuk.com> writes: >> >>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message >>> news:kcppe4$orb$1@speranza.aioe.org... >>> >>>> The way command line expansion is done in current windows is >>>> still surprising to unix users. >>> >>> The most flexible approach would have been to supply a raw, >>> unprocessed command line to a C program. Then it would work exactly >>> the same way as every subsequent line of input. >> >> What does each command here see as it's raw unprocessed command line? >> >> ls -lt $(find . -name data\*) | head -$1 >>out*.log > > On Windows, characters such as |, < and > have special meaning meaning to > the 'shell', so the first command would see: You said "the most flexible approach would have been to...". That sounds like you are saying what would have been better for Unix to have done. I.e. I was asking not what Windows does, but what you think Unix shells should do. > -lt $(find . -name data\*) > > and the next -$1, which I guess has special meaning in Unix, perhaps like %1 > in Windows BAT files. But this is starting to get into scripting now. A few > escapes are acceptable (I was going to say inescapable), and sometimes there > is nothing the invoked program can do with them anyway. > > However, to add "*" to the end of \windows\system32\, and turn that one > parameter, into 2745 parameters, is something that is in a class of > its own. It's simply what it means to most Unix shells. I don't see why it's so odd an idea. You can pass the string "/windows/system32/*" perfectly easily if that's what the program (or the user) wants. > (And imagine that all you'd intended doing with that parameter was to > write it out again as a part of an argument to system(). Or perhaps > changing a *.c spec to a *.o one, which suddenly becomes a bit more > difficult.) Just pass *.c to the program. What's the problem? -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web