commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Csaba Skrabak (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CLI-275) Cannot get a full quoted argument through
Date Wed, 23 Aug 2017 15:57:00 GMT

    [ https://issues.apache.org/jira/browse/CLI-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16138504#comment-16138504
] 

Csaba Skrabak edited comment on CLI-275 at 8/23/17 3:56 PM:
------------------------------------------------------------

[~glennm], I saw the code that removes the double quotes. It's defined and deterministic.
* It will remove only double quotes, does not react to single quotation marks in any way.
* It removes only from the both ends of an argument. It does not remove them from the middle.
If a quotation starts at the beginning of the argument but ends in the middle, or starts in
the middle and ends at the end then it also stays in place.
* It only processes what it gets. So any quotation mark and escape character that is processed
by the shell will behave according to shell rules. Only those quotation marks are subject
to Apache CLI processing that are escaped or quoted to the shell.
* Note that the shell is not necessarily bash or Bourne Shell. It may as well be cmd.exe or
things I don't know about.

So this is a grammar that is defined and tested (although very annoying to bash users.) My
main concern is that this grammar does not contain the string with a pair of double quotes
on both ends. I.e., there is no way to end up in "xx" (including the quotation marks) no matter
how hard the user escapes things.

Passing in an argument like "xx" is exactly what Phoenix would need to interpret a table name
case sensitively.

What is even sadder in this situation is that only a backward incompatible change would solve
the problem.


was (Author: cskrabak):
[~glennm], I saw the code that removes the double quotes. It's defined and deterministic.
* It will remove only double quotes, does not react to single quotation marks in any way.
* It removes only from the both ends of an argument. It does not remove them from the middle.
If a quotation starts at the beginning of the argument but ends in the middle, or starts in
the middle and ends at the end then it also stays in place.
* It only processes what it gets. So any quotation mark and escape character that is processed
by the shell will behave according to shell rules. Only those quotation marks are subject
to Apache CLI processing that are escaped or quoted to the shell.
* Note that the shell is not necessarily bash or Bourne Shell. It may as well be cmd.exe or
things I don't know about.

So this is a grammar that is defined and tested (although very annoying to bash users.) My
main concern is that this grammar does not contain the string with a pair of double quotes
on both ends. I.e., there is no way to end up in "xx" (including the quotation marks) no matter
how hard the user escapes things.

Passing in an argument like "xx" is exactly what Phoenix would need to interpret a table name
case sensitively.

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

Mime
View raw message