The problem is the huge number of sloppy developers of those third party products who themselves did not consider the problem.

It isn't specifically java related, either, and it's a long-standing issue on unix.

Here's an example... Say I want to contatenate two files into a third and the new file has a space in its name, 'foo bar'. Now say one types it like this:

cat file1 file2 >foo bar

The user's shell (bash, csh, sh, ksh, whatever) is going to look at this and use spaces to separate the parameters, just as Windows and Dos also does.

What will end up happening?

  [joi@artoo /tmp]$ cat file1 file2 >foo bar
  cat: bar: No such file or directory

The shell looked at the command and pull out the redirection first. Since it's using space delimiters, it pulls out ">foo" and decides that's supposed to be the new output file, 'foo'. The command string now looks like:

  cat file1 file2 bar

And there is no file bar. Hence the error message. The correct way for me to write this command is:

  [joi@artoo /tmp]$ cat file1 file2 >"foo bar"

  [joi@artoo /tmp]$ ls -la foo*
  -rw-rw-r--    1 joi      joi             0 Jan 17 08:46 foo
  -rw-rw-r--    1 joi      joi             0 Jan 17 08:48 foo bar

So, if I remember to always surround that filename with quotes, life is good. However, now I want to write a script.... Say I do something like this:

  #!/bin/bash
  f1=$1
  f2=$2
  out=$3
  cat $1 $2 >$3

Now if I call this with

  myscript file1 file2 "foo bar"

The shell that parses this command sees the quotes and says "oh, there's a naughty space, I'll strip those quotes and build a execv command for my child shell" like this (in pseudo-c):

  parms[0]="file1";
  parms[1]="file2";
  parms[2]="foo bar";
  execv("myscript", *parms)

So the child shell runs, and it gets those parameters already parsed, and it's happy. But, that 'foo bar' doesn't have quotes in its data stream, it's just foo bar. So when the script runs, it ends up using those parms exactly as provided, and it builds its final cat command like this:

  cat $f1 $f2 >$out
  cat file1 file2 >foo bar

And we're right back to the same problem.

Now, if I was paranoid, I'd have written my script's cat command like this:

  cat "$f1" "$f2" >"$out"

And then I'd be fine.

The problem is, there are way too many apps out there that aren't this paranoid, and those still break when used with multi-word parameters.

There is more than just the one example already given in this thread. One of the big Application Servers JB supports doesn't support them either, and it's commonly whined about around here as well. It became such a problem that people actually suggested Borland prevent users from installing in space-laden directories, just because it caused so many questions from users with that Application Server package.

The problem isn't Borland arbitrarily deciding spaces were evil just to make your life difficult. This issue have been around for decades, and I think it just became too much of a support headache. I know it comes up often, and its in my FAQ just for that reason.

If all programmers were willing to write the extra 2-3 lines of code to handle space-laden command parameters, everything would be fine. But most programmers, being human, are either lazy or uninformed, and don't write them. Hell, most of the time I don't write them, either! Much of the code I write is for myself, and since I never put spaces in my own filenames, I don't waste my time handling a condition I will never create for myself.

See Also: I installed JBuilder in C:\Program Files, and I'm having trouble with my project's classpath. How can I fix this?
2002-Jan-17 9:16am gyles19@visi.com