[
https://issues.apache.org/jira/browse/CLI-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136139#comment-16136139
]
Glenn McCall edited comment on CLI-275 at 8/22/17 1:50 AM:
-----------------------------------------------------------
Agreed, if the Command Interpreter has processed the quotes and presented an
argument in quotes to CLI, then CLI should retain them.
By not doing so, this creates an awfully confusing scenario for end users
trying to explain those familiar with escaping quoted arguments (to bash for
example) to pass quotes to a program only to have different rules apply for an
apache-CLI based program.
Some other scenarios that produce "strange results" when invoked from bash
(format is as entered on command line -> as output from CLI followed by notes
explaining the input string in parenthesis. Correctness or otherwise is as
compared to echo when run on bash - why? because this is how we explain quoting
to end users - try your escaped string in echo to see how it will get passed
through to an application. Here is the "strange results list":
{code:none}
"~" -> ~ (this is correct)
\"~\" -> ~ (INcorrect)
'"~"' -> ~ (single quote - double quote - tilde - double quote - single
quote => INcorrect)
"'"~"'" -> '~' (double - single - double - tilde - double - single - double =>
correct - surprisingly to me, echo produces the same result.)
"'~'" -> '~' (double-single-tilde-single-double) -> Correct)
'""' -> empty string (single-double-double-single) -> INcorrect)
"''" -> '' (double-single-single-double -> single-single -> Correct)
"\"~\"" -> ~ (double - esc double - tilde - esc double - double -> INcorrect).
"\\"~\\"" -> \~\ (double - esc backslash - double - tilde - esc backslash -
double -> correct)
{code}
it seems that CLI has some sort of vendetta against double quotes.
was (Author: glennm):
Agreed, if the Command Interpreter has processed the quotes and presented an
argument in quotes to CLI, then CLI should retain them.
By not doing so, this creates an awfully confusing scenario for end users
trying to explain those familiar with escaping quoted arguments (to bash for
example) to pass quotes to a program only to have different rules apply for an
apache-CLI based program.
Some other scenarios that produce "strange results" when invoked from bash
(format is as entered on command line -> as output from CLI followed by notes
explaining the input string in parenthesis. Correctness or otherwise is as
compared to echo when run on bash - why? because this is how we explain quoting
to end users - try your escaped string in echo to see how it will get passed
through to an application. Here is the "strange results list":
{code:plain}
"~" -> ~ (this is correct)
\"~\" -> ~ (INcorrect)
'"~"' -> ~ (single quote - double quote - tilde - double quote - single
quote => INcorrect)
"'"~"'" -> '~' (double - single - double - tilde - double - single - double =>
correct - surprisingly to me, echo produces the same result.)
"'~'" -> '~' (double-single-tilde-single-double) -> Correct)
'""' -> empty string (single-double-double-single) -> INcorrect)
"''" -> '' (double-single-single-double -> single-single -> Correct)
"\"~\"" -> ~ (double - esc double - tilde - esc double - double -> INcorrect).
"\\"~\\"" -> \~\ (double - esc backslash - double - tilde - esc backslash -
double -> correct)
{code}
it seems that CLI has some sort of vendetta against double quotes.
> Cannot get a full quoted argument through
> -----------------------------------------
>
> Key: CLI-275
> URL: https://issues.apache.org/jira/browse/CLI-275
> Project: Commons CLI
> Issue Type: Bug
> Reporter: Csaba Skrabak
>
> CLI-185 has been partially fixed but user still cannot pass in an argument
> like "x" (the whole argument surrounded by one pair of double quotes.) If
> user enters \"x\" then the quotes get eaten (btw. WHY THE HECK?!). But if
> user enters \"\"x\"\" then both pairs of quotes are left intact.
> The idea of removing the quotes is plain wrong, should be either forgotten
> entirely or the argument should be parsed properly (rather than tinkering
> from bug to bug with variations of find/substring call constructs) with the
> possibility to escape and quote quotation marks.
> Blocks: PHOENIX-3710
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
