Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056933 - [GSS] (6.4) CLI incorrectly parses backslashes in commands
Summary: [GSS] (6.4) CLI incorrectly parses backslashes in commands
Keywords:
Status: VERIFIED
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: 2017-10-10 00:24 UTC (History)
3 users (show)

Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-23 15:24:50 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-2461 Major Closed refactoring of character escaping in operation parameter values 2019-04-08 22:31:22 UTC
Red Hat Bugzilla 1024381 None CLOSED windows paths with '\' as delimiter are not used correctly. '\' is omited 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.