command line arguements with spaces in them

[Alf P. Steinbach]

* Simon Biber:

I have a program which reads in 3 filenames from the command line

prog filename1 filename2 filename3

However, it doesn't work when one of the filenames has spaces in it
(due to a directory name with a space in it) because that filename gets
split into 2.

I tried

prog "/blah/blah 2/filename1" "filename2" "filename3"

and it still splits on the space. (It included the " chars too).

That's strange; what you have given above works on most platforms.

Strictly, the way in which program arguments are supplied is not defined
by the C standard. The C standard does not require that there is such a
thing as a command line, or that arguments are separated by spaces.

<OT>
As Rouben said, on Unix platforms it is up to the shell to parse the
command line and separate out the individual arguments. Unix shells
typically support double quotes, single quotes and also backspace
escaping of spaces.

On the Windows command line, double quotes are supported and will result
in the correct escaping behaviour:

C:\docs\prog\c>testargs "hello world" "foo"
argc = 3
argv[0] = testargs
argv[1] = hello world
argv[2] = foo

But single quotes will not be recognised as anything special:

C:\docs\prog\c>testargs 'hello world' 'foo'
argc = 4
argv[0] = testargs
argv[1] = 'hello
argv[2] = world'
argv[3] = 'foo'

</OT>

Very off-topic I guess, but the above is not quite correct. In Windows
the argument line is passed to the process as-is, and is then split into
separate 'main' arguments by the C run time library. There is a command
line parsing (splitting-into-arguments) API function that the run time
library can use, but usually it's not used, and in one case, an article
published in DDJ (IIRC) by Brian Kernighan (IIRC), the correct working
of an example relied, without mention, on a non-conventional parsing
(expanding wildcards) that is supported by some compilers by applying
suitable compiler or linker switches, and this caused some debate.

 

[Mark McIntyre]

Mark McIntyre said:


You appear to be mistaking "filename" with "complete description in verbose
English of the contents of the file".

Not at all.

If, for example, I have a program to
apply a Bayesian filtering algorithm to my mailbox contents, I am likely to
call it something like "killspam.c".

Now try this with a weekly project report, seventy letters of
complaint to your bank and all your correspondence to your mum.

My point, which I'm sure you get, is that humans find descriptive
names useful. You and me, we're not normal, we're programmers and we
can read hungarian notation FCOL,.

I also ought to point out that both Unix and Windows can handle names
with spaces in just fine.

If i want an exacting description of the file's contents, the filename is not
the place to keep it.

Given that the name of the file is the most commonly seen feature in
any OS you can care to mention, I tend to disagree. (I did notice your
interjection of the word "exacting", but I'm ignoring it since its an
attempt to divert the discussion).

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Rod Pemberton]

ibelievethatwritingwithoutanyspaceswentoutoffashionaround500adwhentheromanss
tartedusingspaces

dylslvtllthvwls?

"Do you also leave out all the vowels?"

Yes, as a matter of fact. I do... Don't you? As you can see they are
unimportant too.


Rod Pemberton

 

[Richard Heathfield]

Mark McIntyre said:

On Sat, 15 Jul 2006 12:52:49 +0000, in comp.lang.c , Richard


Now try this with a weekly project report,
FooReport20060714.tex

seventy letters of complaint to your bank
BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex
....
BankAddrChangeDispute/bacd20060522.tex

and all your correspondence to your mum.

All handwritten, since she doesn't have or want a computer.

My point, which I'm sure you get, is that humans find descriptive
names useful.

Sure. But filenames are not an appropriate place to keep long descriptions.

You and me, we're not normal,

Neither is anyone. Normality is a myth. (Do the math. How many people are
normal in every respect?)

we're programmers and we can read hungarian notation FCOL,.

Nope. Nobody can read Hungarian notation. With the possible exception of
Norwegians.

I also ought to point out that both Unix and Windows can handle names
with spaces in just fine.

What has that to do with anything?

<snip>

 

[Skarmander]

Mark McIntyre said:


Neither is anyone. Normality is a myth. (Do the math. How many people are
normal in every respect?)

There's just this one guy, actually. Some people have started to wonder
whether he isn't unusual for that, but that's another matter.

S.

 

[Rouben Rostamian]

Mark McIntyre said:


What has that to do with anything?

About as much as spaces in filenames have to do with C.

 

[Randy Howard]

Richard Heathfield wrote

(e-mail address removed) said:


Yes. Rename the file so that it doesn't have spaces in it. And the next time
anyone puts a space in a filename on your system, shoot them. It will save
you a lot of hassle.

That would be a nice feature if it was implemented directly via
that mythical electrocuting keyboard feature. How do you
propose it be implemented by OS vendors that ship with filenames
that contain spaces?

 

[Randy Howard]

Keith Thompson wrote

Yeah, and install Windows XP Service Pack 3, available from
redhat.com. }

Redhat is dying on the vine, do try and keep up...

 

[Randy Howard]

Mark McIntyre wrote

Now try this with a weekly project report, seventy letters of
complaint to your bank and all your correspondence to your mum.

Try a google search for "Spotlight", probably combined with "MAC
OS X". There are far, far better solutions already out there
than long-winded filenames.

My point, which I'm sure you get, is that humans find descriptive
names useful.

And some have evolved to the point where looking through long
filename directory listings is no longer the best method of
quickly locating a particular file.

You and me, we're not normal, we're programmers and we
can read hungarian notation FCOL,.

I haven't met anyone in quite a while that is proud of hungarian
notation. That ship has sailed, and I wish it had never docked
in port.

I also ought to point out that both Unix and Windows can handle names
with spaces in just fine.

That's true. It's just all the command line tools and the
shell(s) that suffer.

Given that the name of the file is the most commonly seen feature in
any OS you can care to mention, I tend to disagree.

Not strictly true. Some operating systems allow for
intelligent, rapid access to filename and file contents (and
user-added tag descriptions) of documents, pictures, programs,
etc. without doing so. Other operating systems may catch up
some day.

 

[Mark McIntyre]

FooReport20060714.tex

Makes my point, quite frankly. This is vaguely readable, but only if
you already know the topic.

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

Indeed, well and truly hammered home. This is just plain unreadable.

What has that to do with anything?

I generally find that people who /deliberately/ refuse to use
perfectly good features of their OSen are either
a) idiots or
b) foolishly obsessed with trivia

I don't consider you in the first class.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Mark McIntyre said:

Makes my point, quite frankly. This is vaguely readable, but only if
you already know the topic.

Project name, indication that it's a report, date, file extension. And,
quite frankly, all of the above is unnecessary. The report would be stored
in the Foo project's part of the server, in a "WeeklyReports" section, and
the filestamp carries the date. Even the file extension is unnecessary,
since the nature of the file is evident to anyone who reads it. The only
necessary name would be: <serialnumber>

For those who need wordy descriptions, it may well be that an indexing
document meets their needs nicely.

Indeed, well and truly hammered home. This is just plain unreadable.

Really? I disagree, but readability is in the eye of the beholder, is it
not?

I generally find that people who /deliberately/ refuse to use
perfectly good features of their OSen are either
a) idiots or
b) foolishly obsessed with trivia

You forgot to mention:

c) unconvinced of the utility of said features.

 

[Al Balmer]

Makes my point, quite frankly. This is vaguely readable, but only if
you already know the topic.

If you don't already know the topic, you shouldn't be poking around in
Richard's computer ;-)

 

[Gordon Burditt]

FooReport20060714.tex

Project name, indication that it's a report, date, file extension. And,
quite frankly, all of the above is unnecessary.

I disagree if there's any chance copies of the report would be emailed
around or distributed outside the company LAN. Some of the details
might be moved into the directory name but spreading stuff out over
many directories just makes it harder to find stuff.

The report would be stored
in the Foo project's part of the server, in a "WeeklyReports" section, and
the filestamp carries the date.

This isn't necessarily true while the report is being prepared (when
it's probably on the personal workstation of the person preparing
it), or for backups of that server, or if someone takes the report
home to work on (and doesn't have direct access to company servers
from the Internet at large, which is probably a good thing).

It's unrealistic to assume that the "server for the Foo project" will
never change (for example, because it needs more space or horsepower)
or that backups of the old server will be re-done to move the files
to backups of the new server.

It also doesn't deal with the issue that each person working on the
Foo project may prepare their own report (so there are lots of
weekly reports for a given week), which is combined by the project
leader/manager into an overall status report for upper management
(and which perhaps should not be visible to project members), which
may go further up the chain.

The filestamp carries the date it was modified, *NOT* the period the
report is for. This is an important distinction, since reports
can be written early or late, and can be retroactively modified.

Even the file extension is unnecessary,
since the nature of the file is evident to anyone who reads it.

Really? Windows doesn't seem to think so. The UNIX "file" program
is rather clunky and doesn't always unambiguously figure out what
kind of file it is. And you expect people "reading" it to figure
this out how?

The only
necessary name would be: <serialnumber>

For those who need wordy descriptions, it may well be that an indexing
document meets their needs nicely.


Really? I disagree, but readability is in the eye of the beholder, is it
not?

Gordon L. Burditt

 

[Richard Bos]

Mark McIntyre wrote


Try a google search for "Spotlight", probably combined with "MAC
OS X". There are far, far better solutions already out there
than long-winded filenames.

_If_ you want to waste the disk space, yes.

(No, buying a bigger disk is not an option.)

Richard

 

[Richard Heathfield]

Gordon Burditt said:

I disagree if there's any chance copies of the report would be emailed
around or distributed outside the company LAN.

Well, once I send the file to someone else, the name they use for it is
entirely up to them.

Some of the details
might be moved into the directory name but spreading stuff out over
many directories just makes it harder to find stuff.

No, there are tools for finding stuff. One is even called 'find'.

The filestamp carries the date it was modified, *NOT* the period the
report is for. This is an important distinction, since reports
can be written early or late, and can be retroactively modified.

A perfectly reasonable point. Of course, the document itself will carry the
date(s) to which it applies, as will the index document for the project.

Really? Windows doesn't seem to think so.

Windows's understanding of file extensions is deeply flawed. For instance,
it seems to think that files with an extension of .doc are Word documents.
Well, they might be - but they might not, and often *are* not.

The UNIX "file" program
is rather clunky and doesn't always unambiguously figure out what
kind of file it is.

It seems to cope with ordinary file types easily enough.

And you expect people "reading" it to figure this out how?

If someone sends me data without indicating how to read it, and if I can't
figure it out for myself straight away, I can always drop them an email or
phone them up. Hardly rocket science. Yes, the file extension is a handy
clue, but if it's missing, it's hardly the end of the world.

 

[Randy Howard]

Richard Bos wrote

_If_ you want to waste the disk space, yes.

Sure. It is a tradeoff between usability & performance of
searching versus disk space. One well worth it in many cases.

(No, buying a bigger disk is not an option.)

That's a checkbook problem.

 

[Michael Wojcik]

Makes my point, quite frankly. This is vaguely readable, but only if
you already know the topic.

I find it completely readable.

Indeed, well and truly hammered home. This is just plain unreadable.

I find it completely readable.

I generally find that people who /deliberately/ refuse to use
perfectly good features of their OSen

Since the issue at hand is whether this is a "perfectly good feature",
that's moot.

Clearly, Mark, you find the space character more useful as a
character in identifier names than as a punctuator. Clearly there
are others (myself included) who do not. What's puzzling is your
refusal to believe that the latter group could possibly justify
their choice.

In my case, the space character is both a very convenient punctuator,
thanks to its placement on the keyboard, and one I am well accustomed
to, both from its use in every command language I've every used, and
from its use in English. It would have to be extremely useful as a
member of the set of preferred characters for identifiers to
outweigh those advantages, and for me it is not.

Indeed, judging by various studies that have been done on readability
and my own experience, I think it's unlikely that it's that useful as
an identifier character for most readers of English.

--
Michael Wojcik (e-mail address removed)

Only the obscene machine has persisted
jerky and jockeying and not knowing why
I have never existed. Nor should. -- George Barker

 

[Richard Tobin]

Yes. Rename the file so that it doesn't have spaces in it. And the
next time anyone puts a space in a filename on your system, shoot
them. It will save you a lot of hassle.

[/QUOTE]

Unfortunately, that's not always possible.

The shooting bit is.

-- Richard

 

[Richard Bos]

Richard Bos wrote


Sure. It is a tradeoff between usability & performance of
searching versus disk space. One well worth it in many cases.

And impossible in others.

That's a checkbook problem.

Only for those of us in cushy jobs. In the real world, we have both
limited systems and limited (sometimes barely existent) checkbooks.

Richard

 

[Dave Thompson]

On 15 Jul 2006 00:06:21 -0700, "James Dow Allen"

What is with all the absurd names anyway? I don't have Linux
software for my digital camera so process it via Windoze on
a dual-boot system. Not only are all the names absurd and absurdly
long, but AFAIK there's no easy way to change them in Windoze
except one at a time. I end up booting Linux just to rename my
Windoze files!

<OT> With a few mingw tools and line breaks added for posting:
dir %1 /b | tr -d "\r" |
gawk >renames.bat "-vq=\"" -vr=rename
"{x=$0;sub(/%2/,\"%3\");print r,q x q,q $0 q}"
and then do 'renames'. That should be eliminable by doing system()
within the gawk script, but I don't bother. The -vq is because I can't
find a working way to escape a quoted escaped quote (!) and the -vr
just reduces the ugliness slightly.

- David.Thompson1 at worldnet.att.net