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
pu <(E-Mail Removed)> wrote:
> Since a lot of the discussion is now about modifying the shell's default
> behavior... be aware that *all* other programs expect the shell to do
> globbing, so you'd have to modify them all to do the globbing themselves.


> Not realistic.


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

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

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

rm -rf *

and deleting too many files.

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

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

I pretty often do something like

cd X*

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

-- glen
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-11-2013
Joe Pfeiffer <(E-Mail Removed)> wrote:
> glen herrmannsfeldt <(E-Mail Removed)> writes:
>> JohnF <(E-Mail Removed)> wrote:


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


>> Not quite.


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


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


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


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


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


Yes.

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

But it isn't that bash treats echo and ls differently.
(Which it could, as echo is an internal bash command, and
ls isn't.)

>>> Is there a more general rule behind that behavior?


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

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

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

cd /
find . -name *.c

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

On the other hand,

vi *.c

would start editing *.c.

-- glen
 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-11-2013
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.

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
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-11-2013
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
 
Reply With Quote
 
Joe Pfeiffer
Guest
Posts: n/a
 
      01-11-2013
Shao Miller <(E-Mail Removed)> writes:

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

>>
>> Trying this with ls, I was surprised to learn that JohnF's
>> interpretation is actually correct:
>>
>> snowball:515$ ls a*.c
>> /bin/ls: cannot access a*.c: No such file or directory
>>
>> So 'a*.c' must have actually been passed verbatim to /bin/ls.
>>
>>>> Is there a more general rule
>>>> behind that behavior? I ask because I also have a C program,
>>>> in this case evaluating command-line expressions which can be,
>>>> say, a*b, and I've never (so far) had any problem. Is that just
>>>> lucky because there never happened to be any filename matches?
>>>
>>> csh and tcsh will say
>>>
>>> echo: No match.
>>>
>>> (or whatever program you tried to run)
>>>

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


Rereading Glen's post, I think I misunderstood him. My apologies.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-11-2013
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). 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
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      01-11-2013
On 1/11/2013 15:26, Robert Wessel wrote:
> On Fri, 11 Jan 2013 19:33:24 +0000 (UTC), 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.
>>
>> 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
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-11-2013
Shao Miller <(E-Mail Removed)> 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
 
Reply With Quote
 
Greg Martin
Guest
Posts: n/a
 
      01-11-2013
On 13-01-11 12:26 PM, Robert Wessel wrote:
> On Fri, 11 Jan 2013 19:33:24 +0000 (UTC), 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.
>>
>> 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.


 
Reply With Quote
 
Fred K
Guest
Posts: n/a
 
      01-11-2013
On Friday, January 11, 2013 10:17:42 AM UTC-8, Joe Pfeiffer wrote:
> glen herrmannsfeldt <(E-Mail Removed)> writes: > JohnF <(E-Mail Removed)> wrote: >> BruceS <(E-Mail Removed)> 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) isa bit more complicated than suggested above. >> echo * echoes a list of all files as stated >> echo t*.c echoes test.c because that's the only such file in my /home >> echo a*.c echoes a*.c apparently because there are no a*..c files at all >> So if there are no matches, it reverts to echoing the string rather >> than emitting an error like ls would. > > Not quite. > > ls gives the error when it tries to find the file a*.c and fails. > echo just prints its argument. > > So bash does the same thing in both cases, with different results. > > If a file names a*.c actually existed, then it would match a*.c, > and ls would list it. Trying this with ls, I was surprised to learn that JohnF's interpretation is actually correct: snowball:515$ ls a*.c /bin/ls: cannot access a*.c: No such file or directory So 'a*.c' must have actually been passed verbatim to /bin/ls. >> Is there a more general rule>> behind that behavior? I ask because I also have a C program, >> in thiscase evaluating command-line expressions which can be, >> say, a*b, and I've never (so far) had any problem. Is that just >> lucky because there never happened to be any filename matches? > > csh and tcsh will say > > echo: No match. > > (or whatever program you tried to run) > > -- glen



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

However, if there is at least one match, then the shell passes
the match(es) as argument(s).
--
Fred K
 
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