command line arguements with spaces in them

[raphfrk]

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

[Rouben Rostamian]

In article <11*********************@s13g2000cwa.googlegroups. com>,
<ra*****@netscape.netwrote:

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

The quotation marks are interpreted by the shell before the
arguments are passed to the program. What you have written
above will work on most shells under Unix. Alternatively,
you may protect the space by a backslash, as in:

prog /blah/blah\ 2/filename1 filename2 filename

Something like that may or may not work on other systems.
You may want to ask your question in a newsgroup dedicated
to your system.

--
Rouben Rostamian

[Richard Heathfield]

ra*****@netscape.net said:

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

Is there a quick fix that would be possible here?

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Simon Biber]

ra*****@netscape.net wrote:

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>

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

You'll have to do whatever is necessary to make it work the way you want
on your platform. Detecting the double quotes sounds like a possible option.

--
Simon.

[Al Balmer]

On 14 Jul 2006 07:54:01 -0700, ra*****@netscape.net wrote:

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

Not only is this off-topic here, but it depends on your OS and what
command shell you're using. Ask your question in a newsgroup dealing
with your particular environment.

--
Al Balmer
Sun City, AZ

[raphfrk]

Al Balmer wrote:

On 14 Jul 2006 07:54:01 -0700, ra*****@netscape.net wrote:

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

Not only is this off-topic here, but it depends on your OS and what
command shell you're using. Ask your question in a newsgroup dealing
with your particular environment.

Sorry.

Anyway, I went with using " and manually parsing. The problem was that
it needs to run on UNIX and windows (with the same .c file preferably).

I was wondering if there was some c function that would take any
possible OS and give a standard result.

[Skarmander]

Richard Heathfield wrote:

ra*****@netscape.net said:

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

Is there a quick fix that would be possible here?

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.

It will certainly save you more hassle than trying to convince every Unix
programmer out there that spaces are not the tool of the devil, and users
who want readable file names not criminal.

S.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

ra*****@netscape.net said:

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

Is there a quick fix that would be possible here?

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.

Unfortunately, that's not always possible. Certain operating systems
have top-level directories whose names have spaces in them, making it
difficult or impossible to give a space-free full pathname for many
files.

Nothing in C cares whether file names contains spaces or not. The
filename argument to fopen() is just a string; if the OS allows spaces
in file names, fopen() does too.

As for command-line arguments, main() receives them as a sequence of
strings; again, spaces aren't special. It's up to the calling
environment to pass the correct strings.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

ra*****@netscape.net writes:

Al Balmer wrote:

>On 14 Jul 2006 07:54:01 -0700, ra*****@netscape.net wrote:

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

Not only is this off-topic here, but it depends on your OS and what
command shell you're using. Ask your question in a newsgroup dealing
with your particular environment.

Sorry.

Anyway, I went with using " and manually parsing. The problem was that
it needs to run on UNIX and windows (with the same .c file preferably).

I was wondering if there was some c function that would take any
possible OS and give a standard result.

If your program expects a sequence of file names as command-line
arguments, it should get them. argv[1] should point to a string
containing the first file name, argv[2] to a string containing the
second, and so forth, with argc telling you how many you have.
Normally your program shouldn't care about spaces and quotation marks
(unless needs to do its own special-purpose parsing, but that doesn't
seem to be the case here).

How these strings are passed into your program is up to the calling
environment.

<OT>
On Unix-like systems, for example, assuming

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

is what you type at a shell prompt, your program should see three
arguments; the first one happens to contain a space. None of the
arguments will contain a '"' character. I *think* it's the same for
MS-DOS and Windows. (VMS is more complicated, but there are ways to
do what you want.)
</OT>

Here's a simple program that shows the actual command-line arguments:

#include <stdio.h>
int main(int argc, char **argv)
{
int i;
printf("argc = %d\n", argc);
for (i = 1; i < argc; i ++) {
printf("argv[%d] = \"%s\"\n", i, argv[i]);
}
return 0;
}

If I invoke it as
prog foo bar
I get:
argc = 3
argv[1] = "foo"
argv[2] = "bar"
If I invoke it as
prog "foo bar"
I get:
argc = 2
argv[1] = "foo bar"

If you're not able to get these same results, you'll need to ask in a
newsgroup that's specific to whatever system you're using. If you're
having problems on both Unix and Windows, I suggest posting separately
to two different newsgroups. Be sure to specify your environment
(such as which operating system you're using, what shell you're using,
and the *exact* command line you enter; copy-and-paste it, don't
re-type or paraphrase it).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Fri, 14 Jul 2006 15:23:08 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>ra*****@netscape.net 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.

I have to say, this is pretty silly advice. Do you have a problem with
readable filenames?

My pet hate is OSen that permit carriage returns and newlines in
filenames. Seriously screws grep and awk, I can tell you.
--
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]

Keith Thompson said:

Richard Heathfield <in*****@invalid.invalidwrites:

<snip>

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

Unfortunately, that's not always possible. Certain operating systems
have top-level directories whose names have spaces in them, making it
difficult or impossible to give a space-free full pathname for many
files.

That's easy to solve. Simply remove those directories. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Mark McIntyre said:

On Fri, 14 Jul 2006 15:23:08 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>ra*****@netscape.net 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.

I have to say, this is pretty silly advice.

I suppose you're right - it'd cost a fortune in ammunition.

Do you have a problem with readable filenames?

No - I always use readable filenames, and none of them contains spaces.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Al Balmer]

On 14 Jul 2006 10:58:49 -0700, ra*****@netscape.net wrote:

>
Al Balmer wrote:

>On 14 Jul 2006 07:54:01 -0700, ra*****@netscape.net wrote:

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

Not only is this off-topic here, but it depends on your OS and what
command shell you're using. Ask your question in a newsgroup dealing
with your particular environment.

Sorry.

Anyway, I went with using " and manually parsing. The problem was that
it needs to run on UNIX and windows (with the same .c file preferably).

I was wondering if there was some c function that would take any
possible OS and give a standard result.

It isn't the C program that's the problem. The program will do fine
once you persuade the OS to pass you the strings properly. That's why
I said it's OS and shell dependent.

Keep in mind that your solution may break on a system (or shell) that,
e.g., strips the quotes and gives you the entire string as you
expected before.

I think it's still a good idea to ask in a group dealing with your
environment. Personally, I wouldn't feel comfortable without knowing
why it behaves that way, and when it might decide not to ;-)

--
Al Balmer
Sun City, AZ

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

>Richard Heathfield <in*****@invalid.invalidwrites:

<snip>

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

Unfortunately, that's not always possible. Certain operating systems
have top-level directories whose names have spaces in them, making it
difficult or impossible to give a space-free full pathname for many
files.

That's easy to solve. Simply remove those directories. :-)

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[James Dow Allen]

Richard Heathfield wrote:

Is there a quick fix that would be possible here?

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.

Fifteen years ago (more?), a friend was writing a short story on his
PC using WordStar, and having trouble. I suggested he use a name
with no space. That's not the trouble, he insisted, but sure enough,
some combination of Saves and Opens kept destroying his latest edit.
I don't remember the details, but it was obvious two different
routines,
both invoked from the WordStar environment, treated space differently.

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!

James

[Rod Pemberton]

<ra*****@netscape.netwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...

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

Is there a quick fix that would be possible here? I realise that it
could be fixed by manually detecting the " and creating the 3
filenames. However, if there was a way to write the command line so
that isn't necessary, that would be better/easier.

As others have pointed out, this is environment specific. I had to deal
with the issue for DJGPP and OpenWatcom compilers. For DJGPP, it has an
extension that forces quoted args to remain be passed as is
(_crt0_startup_flags=_CRT0_FLAG_KEEP_QUOTES). Unfortunately, OpenWatcom had
no such nicety. But, OW has an additional function, getcmd(), which allows
you to access the original command line. Using the original command line,
you can loop through and requote or reparse the argv arguments. You
probably need to search for such an extension to C.
Rod Pemberton

[Mark McIntyre]

On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>Mark McIntyre said:

>Do you have a problem with readable filenames?

No - I always use readable filenames, and none of them contains spaces.

Youapparentlyhaveadifferentdefintionofreadabletomo sthumanbeings

ibelievethatwritingwithoutanyspaceswentoutoffashio naround500adwhentheromansstartedusingspaces

dylslvtllthvwls?

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

On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>Mark McIntyre said:

>>Do you have a problem with readable filenames?

No - I always use readable filenames, and none of them contains spaces.

Youapparentlyhaveadifferentdefintionofreadabletomo sthumanbeings

You appear to be mistaking "filename" with "complete description in verbose
English of the contents of the file". 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". I would not be so daft as to call it
"programtoapplyabayesianfilteringalgorithmtomymail boxcontents.c" - if I
want an exacting description of the file's contents, the filename is not
the place to keep it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Joe Wright]

Mark McIntyre wrote:

On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>Mark McIntyre said:

>>Do you have a problem with readable filenames?

No - I always use readable filenames, and none of them contains spaces.

Youapparentlyhaveadifferentdefintionofreadabletomo sthumanbeings

ibelievethatwritingwithoutanyspaceswentoutoffashio naround500adwhentheromansstartedusingspaces

dylslvtllthvwls?

The-hyphen-is-acceptable-in-filenames. Readable?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Frederick Gotham]

Joe Wright posted:

Mark McIntyre wrote:

>On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>Mark McIntyre said:

Do you have a problem with readable filenames?
No - I always use readable filenames, and none of them contains
spaces.

Youapparentlyhaveadifferentdefintionofreadabletom osthumanbeings

ibelievethatwritingwithoutanyspaceswentoutoffashi onaround500adwhentherom
ansstartedusingspaces

dylslvtllthvwls?

The-hyphen-is-acceptable-in-filenames. Readable?

Not_to_mention_the_underscore
--

Frederick Gotham

[Alf P. Steinbach]

* Simon Biber:

ra*****@netscape.net wrote:

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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Mark McIntyre]

On Sat, 15 Jul 2006 12:52:49 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>Mark McIntyre said:

>On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>>No - I always use readable filenames, and none of them contains spaces.

Youapparentlyhaveadifferentdefintionofreadabletom osthumanbeings

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]

"Mark McIntyre" <ma**********@spamcop.netwrote in message
news:tc********************************@4ax.com...

On Fri, 14 Jul 2006 21:42:54 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

Mark McIntyre said:

Do you have a problem with readable filenames?

No - I always use readable filenames, and none of them contains spaces.

Youapparentlyhaveadifferentdefintionofreadabletomo sthumanbeings

ibelievethatwritingwithoutanyspaceswentoutoffashio naround500adwhentheromanss
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
Heathfield <in*****@invalid.invalidwrote:

<snip>

>

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

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>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Skarmander]

Richard Heathfield wrote:

Mark McIntyre said:

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

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]

In article <AM******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:

>Mark McIntyre said:

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

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

--
Rouben Rostamian

[Randy Howard]

Richard Heathfield wrote
(in article <b5********************@bt.com>):

ra*****@netscape.net said:

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

Is there a quick fix that would be possible here?

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 (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Randy Howard]

Keith Thompson wrote
(in article <ln************@nuthaus.mib.org>):

Richard Heathfield <in*****@invalid.invalidwrites:

>Keith Thompson said:

>>Richard Heathfield <in*****@invalid.invalidwrites:

<snip>

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

Unfortunately, that's not always possible. Certain operating systems
have top-level directories whose names have spaces in them, making it
difficult or impossible to give a space-free full pathname for many
files.

That's easy to solve. Simply remove those directories. :-)

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

Redhat is dying on the vine, do try and keep up... :-)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Randy Howard]

Mark McIntyre wrote
(in article <nu********************************@4ax.com>):

On Sat, 15 Jul 2006 12:52:49 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

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

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.

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

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.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Mark McIntyre]

On Sat, 15 Jul 2006 23:49:26 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>FooReport20060714.tex

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

>seventy letters of complaint to your bank

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

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

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

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:

On Sat, 15 Jul 2006 23:49:26 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>FooReport20060714.tex

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.

>>seventy letters of complaint to your bank

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Al Balmer]

On Sun, 16 Jul 2006 23:59:56 +0100, Mark McIntyre
<ma**********@spamcop.netwrote:

>On Sat, 15 Jul 2006 23:49:26 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>>FooReport20060714.tex

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

>

>>seventy letters of complaint to your bank

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

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

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

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.

--
Al Balmer
Sun City, AZ

[Gordon Burditt]

>>>FooReport20060714.tex

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

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.

>>>seventy letters of complaint to your bank

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

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?

Gordon L. Burditt

[Richard Bos]

Randy Howard <ra*********@FOOverizonBAR.netwrote:

Mark McIntyre wrote
(in article <nu********************************@4ax.com>):

On Sat, 15 Jul 2006 12:52:49 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

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.

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:

>>>>FooReport20060714.tex

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.

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 report would be stored
in the Foo project's part of the server, in a "WeeklyReports" section, and
the filestamp carries the date.

<snip>

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

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Randy Howard]

Richard Bos wrote
(in article <44****************@news.xs4all.nl>):

Randy Howard <ra*********@FOOverizonBAR.netwrote:

>Mark McIntyre wrote
(in article <nu********************************@4ax.com>):

>>On Sat, 15 Jul 2006 12:52:49 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

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.

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.

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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Michael Wojcik]

In article <n1********************************@4ax.com>, Mark McIntyre <ma**********@spamcop.netwrites:

On Sat, 15 Jul 2006 23:49:26 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

FooReport20060714.tex

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

I find it completely readable.

seventy letters of complaint to your bank

BankAddrChangeDispute/bacd19930513.tex
BankAddrChangeDispute/bacd19930604.tex

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

I find it completely readable.

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?

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 mi************@microfocus.com

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

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

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

>Unfortunately, that's not always possible.

The shooting bit is.

-- Richard

[Richard Bos]

Randy Howard <ra*********@FOOverizonBAR.netwrote:

Richard Bos wrote
(in article <44****************@news.xs4all.nl>):

Randy Howard <ra*********@FOOverizonBAR.netwrote:

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.

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

And impossible in others.

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

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"
<jd*********@yahoo.comwrote:
<snip>

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!

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

[Michael Wojcik]

In article <d4********************************@4ax.com>, Dave Thompson <da*************@worldnet.att.netwrites:

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!

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

[OT]

Under XP, with Command Extensions enabled[1]:

for %a in ("* *") do (
for /f "tokens=1,*" %b in ('echo %a') do ren "%a" "%b%c"
)

will remove the first space from any filename containing at least one
space in the current directory. (The outer for selects files with at
least one space in their names; the inner for parses the names into
prefix and suffix, delimited by the first space, and renames them
with that first space removed.)

Personally, I have and in most cases prefer the Unix utilities, but
for people who don't have or know them, cmd.exe will generally do
this sort of thing, once you master its arcane syntax and odd corner
cases.
[1] Command Extensions is an option for cmd.exe which can be enabled
by setting some Registry key. It's documented in all of the usual
places. It should be enabled; it makes cmd.exe moderately useful.

--
Michael Wojcik mi************@microfocus.com

My IDE is the command line. I'll switch when someone writes something
better.