zowe-cli: Type stringOrEmpty not working as expected
It appears that type stringOrEmpty when defining options is erroneously being validated the same as string. Here is what I found.
public static EJES_OPTION_HELP_APP: ICommandOptionDefinition = {
name: "helpApp",
aliases: ["ha"],
description: "Invoke application specific help.",
type: "stringOrEmpty",
// defaultValue: "usage",
group: EjesProfile.GLOBAL_OPTIONS
};
But when I run the Zowe, I get this:
PS C:\Users\Robert\projects\eclipse\zowe> zowe ejes query status --helpApp
Syntax Error:
No value specified for option:
--helpApp
This option requires a value of type:
stringOrEmpty
Option Description:
Invoke application specific help.
:
Just in case the “option requires a value” means a null string, I’ve tried issuing that:
PS C:\Users\Robert\projects\eclipse\zowe> zowe ejes query status --helpApp ""
Syntax Error:
No value specified for option:
--helpApp
This option requires a value of type:
stringOrEmpty
Option Description:
Invoke application specific help.
:
It appears to me that the stringOrEmpty code is being ignored. My intuition is bolstered by the text of the generated help topic when I run Zowe with –help. Note that the option help below states string not stringOrEmpty, which is shown as coded in my option definition at the top of this issue report.
GLOBAL OPTIONS
--------------
--helpApp | --ha (string)
Invoke application specific help.
I’ve tried coding a default value (I’ve commented it out in my code example). I’ve tried using a different option name, like --info. None of this works. If I do specify an argument, the option works like a champ.
PS C:\Users\Robert\projects\eclipse\zowe> zowe ejes query status --helpApp refine
HELP FOR "Refining the First Row"
The number of rows populating a table depends on selection criteria. The --table
and --report options operate only on the first row of a table. To best use these
:
This appears to be a bug. Please fix it.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 1
- Comments: 17 (6 by maintainers)
This seems to be an unfortunate deviation in the behavior of PowerShell compared to other shells. In PowerShell v3-7 (not sure about earlier versions), an empty argument cannot be passed to an executable without escaping it.
This issue has been discussed on StackOverflow, and several ways have been suggested to escape the characters
"":`“`”"''"'""'[String]::EmptyNeeding to escape the characters is not an ideal solution, however I tested all of these methods and they worked for passing a “stringOrEmpty” argument to Zowe CLI.
Due to the way Imperative parses CLI args (using the
yargspackage), an empty string cannot be specified like this:zowe ejes query status --helpAppInstead an empty string must explicitly be passed:
zowe ejes query status --helpApp ""The only type of CLI arg that can be used without providing an associated value is a boolean option.
I like your original title 😃
I will apologize ahead of time for the tone of my reply, but I am truly flabbergasted.
Really?
Please note that I wrote:
@tjohnsonBCM That workaround does not work.
If it did work, I would use it.
Frankly. Think about it. What enterprise-level command line interface would work this way? What non-enterprise-level CLI would work this way?
Command line programs have existed on “workstation platforms” since the early 1970’s when Unix was developed with C. This and all subsequent platforms allowed developers to write what we now call options that optionally took an argument. That’s because the developer parsed the argv or equivalent in their own code. I can see that stringOrEmpty was intended to fix a design flaw in the Zowe imperative. That some developer chose a “yargs” package to fast-track development of the command parser is not an excuse for a deficiency.
May I suggest writing a parser in Typescript to replace it? Parsers are programming 101 level work and shouldn’t take long.