You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 13, 2023. It is now read-only.
In most command line interfaces, single character options use a single dash. In Zowe, this seems to be true only when the single character option is defined as an alias.
Nevertheless, single character options defined using the name property are accessible with a single dash option on the command line but are rendered in the text and web help with double-dashes. That they can be accessed with a single dash is only true by a quirk of Zowe's programming. For an arbitrary sample option c, Zowe sends an argument array with a "c" property to provide the value to the program regardless of whether the user coded -c or --c on the command line. In any case, Zowe does not flag it as an error.
For example, in an options array on a ICommandDefinition I have: { name: "c", group: QUERY_OPTIONS, type: "string", description: "A list of comma separated, case-insensitive names of columns to include in...
Help renders this:
--c (string)
A list of comma separated, case-insensitive names of columns to include in...
As pointed out above, Zowe doesn't break, but my Zowe program passes the command line not its internal array to consumer modules. Perhaps just as bad, the help generated by Zowe is is flat out wrong as far as the user is concerned. This application simulates an interface and uses options that reflect one character options in that interface. The -c option is the c parameter. I can't change that.
I think assuming double dash for a single character option name is a design oversight. I don't think it was intentional to assume all options will always have two dashes and that only an single character alias can have one dash. That's... I'm not sure what that is. I don't know if this becomes a breaking change, or not. If it is considered such, I'd vote for a NameIsSingleDash property being added. Otherwise, see my first line above.
PS C:\Users\Robert> zowe -V
6.32.0
The text was updated successfully, but these errors were encountered:
In most command line interfaces, single character options use a single dash. In Zowe, this seems to be true only when the single character option is defined as an alias.
Nevertheless, single character options defined using the name property are accessible with a single dash option on the command line but are rendered in the text and web help with double-dashes. That they can be accessed with a single dash is only true by a quirk of Zowe's programming. For an arbitrary sample option c, Zowe sends an argument array with a "c" property to provide the value to the program regardless of whether the user coded -c or --c on the command line. In any case, Zowe does not flag it as an error.
For example, in an options array on a ICommandDefinition I have:
{ name: "c", group: QUERY_OPTIONS, type: "string", description: "A list of comma separated, case-insensitive names of columns to include in...
Help renders this:
As pointed out above, Zowe doesn't break, but my Zowe program passes the command line not its internal array to consumer modules. Perhaps just as bad, the help generated by Zowe is is flat out wrong as far as the user is concerned. This application simulates an interface and uses options that reflect one character options in that interface. The -c option is the c parameter. I can't change that.
I think assuming double dash for a single character option name is a design oversight. I don't think it was intentional to assume all options will always have two dashes and that only an single character alias can have one dash. That's... I'm not sure what that is. I don't know if this becomes a breaking change, or not. If it is considered such, I'd vote for a NameIsSingleDash property being added. Otherwise, see my first line above.
PS C:\Users\Robert> zowe -V
6.32.0
The text was updated successfully, but these errors were encountered: