[
https://issues.apache.org/jira/browse/CASSANDRA-11888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15603777#comment-15603777
]
Murukesh Mohanan commented on CASSANDRA-11888:
----------------------------------------------
The {{bin/cassandra}} script relies on unquoted expansion of {{$JVM_OPTS}} to
split supplied options to separate arguments. Unfortunately, there's no simple
way to safeguard spaces in an environment variable that gets included in this
unquoted expansion (no combination of quoting or backslash-escaping can help).
The simplest way out of this problem is to use a script whenever the command
you need to run contains whitespace or globs ({{?}}, {{*}}, etc.).
More modern shells support arrays, which can help with keeping arguments
separate, but the first step of dealing with multiple options in
{{$JVM_EXTRA_OPTS}} which are separated by whitespace, and any of which might
contain whitespace themselves remains a problem. This cannot be fixed by simple
changes (options include reading in all options from a file and using something
like {{xargs}} to create the command, or restricting {{$JVM_EXTRA_OPTS}} to a
single option so that whitespace can be preserved for it, or some ugly hack
involving {{eval}}).
{{bin/cassandra}} also has this note at the start, after the boilerplate:
{code}
# NB: Developers should be aware that this script should remain compatible with
# POSIX sh and Solaris sh. This means, in particular, no $(( )) and no $( ).
{code}
This means using a modern shell is out of the question, so something like the
following can't be used, where we take advantage of bash's {{read}}'s ability
to handle escaped input:
{code}
bash-4.4$ JVM_EXTRA_OPTS='-XX:foo\ bar\ \*'
bash-4.4$ JVM_OPTS='-XX:blah'
bash-4.4$ JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
bash-4.4$ printf "%s\n" "$JVM_OPTS" | while read -a args; do printf "|%s|\n"
"${args[@]}" ; done
|-XX:blah|
|-XX:foo bar *|
{code}
Workarounds like reserving a character like tab for this could also break
things for others who rely on the default IFS (space, tab, newline).
I suppose this issue should be closed as won't fix.
Related: [Is it possible to “protect” an IFS character from field splitting? -
Unix & Linux|http://unix.stackexchange.com/q/318460/70524]
> cassandra-env.sh may not work properly with jvm args containing a space
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-11888
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11888
> Project: Cassandra
> Issue Type: Bug
> Environment: linux
> Reporter: Russ Hatch
> Priority: Minor
> Labels: lhf
>
> When using the JVM_EXTRA_OPTS environment variable, it looks like there's
> some cases that may not work if an env var contains a space.
> For example, setting:
> {noformat}
> export JVM_EXTRA_OPTS='-XX:OnOutOfMemoryError="echo oh_no"'
> {noformat}
> Results in the jvm not starting because the resultant startup command looks
> to java like it should load a class called oh_no.
> {noformat}
> Error: Could not find or load main class oh_no
> {noformat}
> I think this results from the last line of cassandra-env.sh, where it does
> this:
> {noformat}
> JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
