Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Command line arguments

 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-11-2013
Greg Martin <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Kenny McCormack
Guest
Posts: n/a
 
      01-11-2013
In article <kcppe4$orb$(E-Mail Removed)>,
glen herrmannsfeldt <(E-Mail Removed)> wrote:
>88888 Dihedral <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
BartC
Guest
Posts: n/a
 
      01-11-2013
"glen herrmannsfeldt" <(E-Mail Removed)> wrote in message
news:kcppe4$orb$(E-Mail Removed)...

> 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

 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      01-12-2013
On Friday 11 January 2013 18:46, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> "glen herrmannsfeldt" <(E-Mail Removed)> wrote in message
> news:kcppe4$orb$(E-Mail Removed)...
>
>> 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"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-12-2013
Robert Wessel <(E-Mail Removed)> writes:

> On Fri, 11 Jan 2013 20:49:48 +0000 (UTC), glen herrmannsfeldt
> <(E-Mail Removed)> wrote:
>
>>Robert Wessel <(E-Mail Removed)> 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.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-12-2013
Fred K <(E-Mail Removed)> 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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-12-2013
"BartC" <(E-Mail Removed)> writes:

> "glen herrmannsfeldt" <(E-Mail Removed)> wrote in message
> news:kcppe4$orb$(E-Mail Removed)...
>
>> 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.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-12-2013
Ben Bacarisse <(E-Mail Removed)> 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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-12-2013
Fred K <(E-Mail Removed)> 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.
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      01-12-2013


"Ben Bacarisse" <(E-Mail Removed)> wrote in message
news:0.511e5c58ec135e522e0c.20130112013227GMT.87d2 (E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:
>
>> "glen herrmannsfeldt" <(E-Mail Removed)> wrote in message
>> news:kcppe4$orb$(E-Mail Removed)...
>>
>>> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


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



Advertisments