[zkhalique]

Oh brother, this is one of the reasons UNIX was much more developer-friendly.

[agentgt]

Actually Bash does have some issues with command line arguments if doing variable expansion. For example in Java apps it is actually fairly difficult to pass -DsomeParameter="something with a space in it" if doing variable expansion.

[marcosdumay]

But it's bash that has those issues, not the OS.

If it's an issue for you on Linux, you can always run a python shell and spawn your process there. On Windows you can't.

[grymoire1]

It's a bash programmer issue, not a bash issue.

If you want spaces to be unparsed in parameters, you "quote" the parameter.

  A="spaces in the argument"
  touch "$A"
  ls -l

   total 0
   -rw-rw-r-- 1 me me 0 Dec 27 15:40 a file with spaces

[kbp]

Could you clarify what you mean? What's wrong with -DsomeParameter="$var"? Or am I misunderstanding?

[agentgt]

I'm trying to find the exact situation but basically if you have something like:

   PROPS="-Dprop1=foo bar -Dprop2=bar foo"

   java $PROPS SomeClass.class

You can try to escape with backslashes and what not but it becomes fairly hard if not impossible to expand multiple parameters correctly as a single variable. I believe one solution is to use arrays and another is just not use arguments and instead rely on other configuration mechanisms (env variables, files, etc).

You see this often rear its ugly head with daemon scripts.

[colemickens]

A bit hard to understand your exact scenario here (basically the same shell lexing problem...), but I think this is what you're looking for.

I left an example of an argument with a space in there (the last one).

    PROPS=("-Dprop1=foo" "bar" "-Dprop2=bar foo")
    java "${PROPS[@]}" SomeClass.class

(The quotes around `${PROPS[@]}` is important.) Do note, there is an unfortunate edge case here if PROPS is empty, you'll get a false `""` arg passed to java in that case. There's a less pleasant syntax that avoids that issue but I don't recall it off-hand.

(edit: Please read the replies to my post, I didn't think about the fact that this syntax is bash specific. Thanks to those who pointed it out)

[agentgt]

Oh I am sure there are ways around it but the big issue is that almost all of the daemon scripts out there do not do it. That is you can't just set some configuration in /etc/default/some_daemon as the script will try to concatenate the command.

I tried to find a failsafe solution once while rewriting a daemon script and just gave up.

[hashhar]

That's a bashism I think and hence not as portable as POSIX shells.

[hwc]

This is, of course, a bashism.

[hk__2]

Can't you quote each argument?

     PROPS="'-Dprop1=foo bar' '-Dprop2=bar foo'"

[EvilTerran]

Sadly not: only quotes that appeared literally in the command-as-written affect word-splitting or are subject to quote removal, not those resulting from an expansion step (variable substitution, globbing, etc); so you'd end up with four elements in argv (or one if you double-quoted the variable reference), with literal single-quote characters in them. You'd have to do something unpleasant with "eval" to make that work.

It's a sensible rule, when you think about it - otherwise, for example, an expansion that introduced mismatched quotes would cause total chaos.

[grymoire1]

You can include quotes in arguments on Unix systems. The only tricky bit is getting meta-characters past the shell to the command the shell executes.

Example

  #!/bin/bash
  Q1="'"
  Q2='"'
  echo "$Q1$Q2"

This prints

  '"

And if you really understand that ' and " turn quoting on and off anywhere in the line, you can combine these two into a single variable:

  #!/bin/bash
  Q1="'"'"'
  echo "$Q1"

[dozzie]

I think the parent misattributed where the fsckup was. Most probably it wasn't bash or other shell as it is, it probably was broken /usr/bin/java script (yes, it used to be a shell script) that looked for Java bytecode interpreter in various places. As most scripts that come from a big company, its style was terrible.