Bug 824129
| Summary: | JON CLI - Parameters to exec command not parsed correctly when using quotes | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Jochen Cordes <jcordes> | ||||||||
| Component: | CLI | Assignee: | John Sanda <jsanda> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 4.4 | CC: | hrupp, jsanda | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | RHQ 4.5.0 | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | |||||||||||
| : | 826604 (view as bug list) | Environment: | |||||||||
| Last Closed: | 2013-09-01 10:17:02 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: | |||||||||||
| Bug Depends On: | 829309 | ||||||||||
| Bug Blocks: | 826604 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 586141 [details]
The script that receives the parameters
Created attachment 586143 [details]
A library script
per BZ Triage 5/29/2012 (ccrouch, loleary, asantos, mfoley, myarborough) moving these to JON 3.1.1 or later I am not sure why, but we were treating both single and double quotes as regular words/symbols as opposed to quote delimiters. I have checked in a fix to master. commit hash: 522ff41ba7 This commit fixes the immediate problem, but I believe that there is a larger, more fundamental problem that needs to be addressed. CLI code is JavaScript with the exception of a handful of built in commands. So we have the majority of code that is written and executed as JavaScript, and then we have a small fixed set of commands that executes as Java. Because of this we have multiple layers of parsing code. These multiple layers of parsers has led to this bug as well as bug 813912, and others. To make things even worse, not all of these built-in commands are available in batch mode. I strongly believe that the best solution is to completely do away with these built-in commands. The functionality provided by the built-in commands should be implemented within the framework in which users operate; in other words, the functionality should be exposed via functions and methods of objects that are available in the script bindings. In so we doing, we can eliminate most if not all of these buggy parsing layers, provide a uniform and consistent syntax, and take better advantage of the features that JavaScript has to offer (if we so choose). I will post this info to the devel list for additional feedback and based on that feedback open up another bug to track this. Added fix for bug 829309. The parsing changes now only take effect for the script arguments in the command line. The commit has been pushed to master. commit hash: 5e8863403 Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since. |
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 4.4.0.310BETA1 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 2. 3. 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: