Open Vinodjayakumar124 opened 1 year ago
Thanks for the bug report, but as seen from the screenshot of the UG provided above, the RandomText
argument is placed at the FLAG
portion of the command. Therefore, it is reasonable that RandomText
has been read as a flag and the 'Unknown flag' response is appropriate. Furthermore, the UG mentions that flags are supposed to start with a dash, but precisely because the dash is missing makes RandomText
qualify as an invalid flag, and hence the flag is "unknown" to DevEnable.
Team chose [response.Rejected
]
Reason for disagreement: I can appreciate the Team's perspective that the RandomText has been placed at flag position and therefore they have termed it an unknown flag.
However, from the user's perspective they have meant for the RandomText to be the additional parameter supplied to commands such as find (i.e the n/DevEnable
in project -f n/DevEnable
).
The error message returned in this case "Unknown flag" will not be helpful for the User as he has not input any flag at all. Hence, the application has to be more robust to validate if the characters at the flag position has a dash (i.e -
) or not and return an error message accordingly.
For erroneous commands, should there be a dash, then the error could be "Unknown flag". Otherwise, if there is no dash, then "No flag supplied" should be returned as an error. The current implementation does not distinguish between the two cases and may pose as a source of confusion for the User. Hence, I have given this issue a Low
severity.
Error message produced when any random characters are used after and of the three command returns "unknown flag".
However, UG defines flag as beginning with a dash
Error: