Bug 1056933 - [GSS] (6.4) CLI incorrectly parses backslashes in commands
Summary: [GSS] (6.4) CLI incorrectly parses backslashes in commands
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CLI
Version: 6.2.0,6.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DR1
: EAP 6.4.0
Assignee: Alexey Loubyansky
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-23 08:16 UTC by Radim Hatlapatka
Modified: 2019-08-19 12:45 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-01-23 15:24:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1024381 0 unspecified CLOSED windows paths with '\' as delimiter are not used correctly. '\' is omited 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker WFLY-2461 0 Major Closed refactoring of character escaping in operation parameter values 2019-04-08 22:31:22 UTC

Internal Links: 1024381

Description Radim Hatlapatka 2014-01-23 08:16:15 UTC
Description of problem:
Backslashes are incorrectly handled by CLI:
* In case of using one backslash, it is lost, 
* In case of using double backslash without quotes it results in four backslashes
* In case of using double backslash in quotes, it gives the desired result of two backslashes


How reproducible: always


Steps to Reproduce:
1. via cli try to change attribute value for any resource (e.g. /system-property=aaa:add(value=c:\tmp))
2. then read the resource (e.g. /system-property=aaa:read-attribute(name=value))
3. compare your input value and the output

Actual results:
the number of backslashes behaves strangely and doesn't allow to put one backslash as result value

Expected results:
Consistent behavior of backslashes allowing to insert as result one backslash


Additional info:

Comment 1 Radim Hatlapatka 2014-01-23 09:17:43 UTC
The main issue is the inconsistency

Comment 2 Alexey Loubyansky 2014-01-23 15:24:50 UTC
You have to be specific. Are you sure I will see the same outcome as you are?
I did run your operation and it looks right.

Did you read the issue you are referring to? It's resolved as NOTABUG.

If it doesn't meet your expectations, it doesn't mean its inconsistent.

'\' is a special character used for escaping. Just like in Java.

Everything below is the expected output.

[standalone@localhost:9990 /] /system-property=aaa:add(value=c:\tmp)
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=aaa:read-attribute(name=value)
{
    "outcome" => "success",
    "result" => "c:tmp"
}

[standalone@localhost:9990 /] /system-property=aaa:remove
{"outcome" => "success"}
[standalone@localhost:9990 /] /system-property=aaa:add(value=c:\\tmp)
{"outcome" => "success"}

The following is the *DMR* format
[standalone@localhost:9990 /] /system-property=aaa:read-attribute(name=value)
{
    "outcome" => "success",
    "result" => "c:\\tmp"
}

And this is the *actual* value
[standalone@localhost:9990 /] read-attribute --node=system-property=aaa value
c:\tmp

If you execute the lines above and get different results, you can re-open the issue (it will also mean the issue has been fixed).

Comment 3 Radim Hatlapatka 2014-01-23 15:56:03 UTC
If it is an escape character as in Java, why \t is not translated as tabulator?

If I try add it as c:\\tmp this is what I get with EAP 6.2.0:

[standalone@localhost:9999 /] /system-property=aaa:add(value=c:\\tmp)
{"outcome" => "success"}
[standalone@localhost:9999 /] /system-property=aaa:read-attribute(name=value)
{
    "outcome" => "success",
    "result" => "c:\\\\tmp"
}


[standalone@localhost:9999 /] read-attribute --node=system-property=aaa value
c:\\tmp


I am able to get your results if I put the value to quotes =>
[standalone@localhost:9999 /] /system-property=aaa:add(value="c:\\tmp")


I call that inconsistency as for one backslash in quotes and without qoutes it behaves the same, but if I put two backslashes, it differs

Comment 4 Alexey Loubyansky 2014-01-23 16:40:13 UTC
Thanks. Sorry for being harsh.

Comment 6 Radim Hatlapatka 2014-09-19 12:31:12 UTC
Verified in EAP 6.4.0.DR1.1


Note You need to log in before you can comment on or make changes to this bug.