This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 826604 - JON CLI - Parameters to exec command not parsed correctly when using quotes
JON CLI - Parameters to exec command not parsed correctly when using quotes
Product: RHQ Project
Classification: Other
Component: CLI (Show other bugs)
i686 Linux
high Severity medium (vote)
: ---
: JON 3.1.1
Assigned To: John Sanda
Mike Foley
Depends On: 824129 829309
  Show dependency treegraph
Reported: 2012-05-30 11:20 EDT by John Sanda
Modified: 2013-09-03 11:08 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 824129
Last Closed: 2013-09-03 11:08:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description John Sanda 2012-05-30 11:20:50 EDT
+++ This bug was initially created as a clone of Bug #824129 +++

Created attachment 586140 [details]
Script with input redirection

Description of problem:

Parameters to exec command not parsed correctly when using quotes (single/double) around value

Version-Release number of selected component (if applicable):

RHQ Remoting Client

How reproducible:

Call a script with an index parameter in the exec command when using JON CLI in interactive mode

Steps to Reproduce:
1. Call a script that does input redirection including exec command
Actual results:

The value of the parameter as retrieved via args[0] contains the quotes and ends with character before the first space

Expected results:

The value of the parameter is the value between the quotes.

Additional info:

--- Additional comment from on 2012-05-22 15:33:27 EDT ---

Created attachment 586141 [details]
The script that receives the parameters

--- Additional comment from on 2012-05-22 15:36:40 EDT ---

Created attachment 586143 [details]
A library script

--- Additional comment from on 2012-05-29 10:41:28 EDT ---

per BZ Triage 5/29/2012 (ccrouch, loleary, asantos, mfoley, myarborough) moving these to JON 3.1.1 or later
Comment 1 John Sanda 2012-07-20 10:30:42 EDT
Pushed commits to release/jon3.1.x branch to handle quotes.

commit hash: 522ff41ba7
commit hash: 5e88634033d
Comment 2 John Sanda 2012-08-02 14:52:05 EDT
JON 3.1.1 ER1 build is available. Moving to ON_QA.
Comment 3 Filip Brychta 2012-08-09 10:32:46 EDT
Works correctly for indexed arguments, failed for named argumets.
for (i in args) {
     println('args[' + i + '] = ' + args[i]);
println("start;"+ x + ";end");
println("start;"+ y + ";end");

exec -f scripts/start-web-app-instance.js --args-style=named x=1 y=2

args[0] = 1
args[1] = 2


exec -f scripts/start-web-app-instance.js --args-style=named x="aa" y="bb"

args[0] = null
args[1] = null
args[2] = null
args[3] = null

Comment 4 John Sanda 2012-08-16 14:01:57 EDT
I have pushed a commit to the release/jon3.1.x branch to address the issues with parsing quoted strings in named arguments.

commit hash: e5d912de85a

I want to make it very clear that I am not entirely comfortable with making this change because there are more fundamental problems with the parsing as well as with the built-in commands, e.g., exec, login, logout, etc. You can invoke to run a script in non-interactive mode as follows,

$ -f myscript.js --args-style=named x=foo y=bar

We use a Java version of the Getopt library to parse the command line. This enables us to provide a command line interface for passing arguments and options that is consistent with most other unix/linux command line utilities and programs. When running in interactive mode, we would execute the above command line as,

$ exec -f myscript.js --args-style=named x=foo y=bar

We use the same Getopt parsing for the command line in the interactive shell. There is a fundamental problem here. The interactive shell is *supposed* to be a JavaScript shell with RHQ extensions that come in the form of additional objects and functions; however, it is not a 100% JavaScript. If it were 100% JavaScript, the interpreter would complain that foo and bar are undefined, but we instead treat foo and bar as literal strings. Let me illustrate the problem here with another example (assume that myscript.js just prints the value of x). 

$ myvar = "my var"
$ exec -f myscript.js --args-style=name x=myvar

The script will output the string "myvar, not "my var". This means the value of a named argument cannot be any valid JavaScript expression; however that is what should be supported. 

I described what I firmly believe is the most appropriate solution here Earlier I mentioned that there are several "built-in" commands including exec, login, and logout. What exactly do I mean by that? Those commands are built directly into the CLI's interactive shell. When you execute a statement in the interactive shell, it is parsed to see what built-in command to execute. If the statement is,

$ logout

Then the appropriate Java method is invoked to perform the logout action. If the statement is something like,

$ myVar = {x: 123, y: function() { return "love craft beer";}}

That statement will be passed directly to the JavaScript interpreter since there it does not contain a built-in command. But if the statement is,

$ exec myVar = {x: 123, y: function() { return "love craft beer";}}

The appropriate Java method is called to parse the statement. In this case, the bulk of the parsing is handled by the JavaScript interpreter. But if we do,

$ exec -f myscript.js arg1 arg2

We execute the same parsing logic that is used to parse and execute scripts from the bash shell via When you run a script in non-interactive mode, the script is passed directly to the JavaScript interpreter. Because of these inconsistencies, we have functionality available in the interactive shell that is not available in non-interactive mode, namely the exec command. This has all led to hard to maintain, buggy code.

The solution is rather straightforward. We need to do away with these commands that are built into the CLI shell. They should be replaced with objects and/functions that are available in the script bindings. This has some major benefits. First, we can eliminate this error-prone parsing that we do in the interactive shell. The parsing can be handled by the JavaScript interpreter. Secondly, the environment will be consistent across both interactive and non-interactive modes. Thirdly, everything is standard JavaScript (or any other supported scripting lang) which means users do not have to learn or understand any additional syntax. 

So instead of an exec command, we would provide an exec function (that is properly name spaced) that might be used as follows,

$ exec("myscript.js", arg1, arg2)

Since JavaScript does not support named arguments we can do,

$ exec("myscript.js", {namedArg1: "foo", namedArg2: "bar"})

No extra, special parsing required. It's all just standard JavaScript.
Comment 5 John Sanda 2012-08-16 16:59:38 EDT
Part of comment 4 needs a bit of clarification. I said that I was not entirely comfortable with the change because it addresses this specific issue and not the broader issues which I described in greater detail. I have tested the changes locally and am confident that they fix the problems described in comment 3. As for the broader, more fundamental issues, those would likely come in a major release. I will raise a separate bug for these other issues after discussion on the community mailing list (rhq-devel).
Comment 6 John Sanda 2012-08-22 01:38:07 EDT
Moving to ON_QA. The JON 3.1.1 ER3 build is available at
Comment 7 Filip Brychta 2012-08-24 08:57:51 EDT
Verified on JON 3.1.1 ER3
Comment 8 Heiko W. Rupp 2013-09-03 11:08:13 EDT
Bulk closing of old issues in VERIFIED state.

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