Bug 1056933

Summary:	[GSS] (6.4) CLI incorrectly parses backslashes in commands
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Radim Hatlapatka <rhatlapa>
Component:	CLI	Assignee:	Alexey Loubyansky <olubyans>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Kremensky <pkremens>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.2.0, 6.2.1	CC:	bbaranow, brian.stansberry, kkhan
Target Milestone:	DR1	Keywords:	Reopened
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-01-23 15:24:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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