New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow flags to precede required positional arguments #124
Comments
Note: that might feet in a more general issue/discussion, feel free to tell me where to move it or to do it yourself. The piece that makes most of us presuming pre-operand options :
While not enforcing pre-operand option feels like a good relaxe from the standards, Also, regarding option at the end, they are historically enforced before operands to deal easily with the ability to distinguish dashes from option versus operands.
This is highly convential thing that solves so many problems and might be implemented in the same PR. Additionnally but less important, there are some other guidelines that are very practical when supported by cli parsing :
Being able to tell a list without having to quote it is realy satisfying (but I recon this is nowadays rarely implemented unless specifically said, or partially implemented (e.g only when using the awfull = and comma separated list).
Enforcing every "non option argument" as positional is very limiting. All in all, positional arguments are limitating, and quite rare unless you manipulate e.g. files, and again most of the time the only position considered is "all the previous operands" vs the last one as to distinguish a list from it's containers (e.g cp/mv/ln etc). Also pure positionals or option at end breaks the ability to do things like command line after the -- in docker run
Unless I again fail to find immediate implementation, I feel that actual bashly state breaks the ability to take stdin as input this way. |
Well - bashly never claimed to be compliant with any standard, nor does it strive to do so. Lets not forget, that this is a bash script after all, and it is unlikely to support everything that can be done in the command line. We have enabled the Discussions tab, so we have a better place to discuss such things without the obligation to "solve" them :) |
Not at all telling that posix should be followed. Bash is not posix, and that's what we talk about. |
I just realized that the problem is only with positional arguments that are marked as |
@cjbrigato - I have implemented a change that fixes this, it is merged to the master branch. Thanks for this issue, it was an important change. |
Thanks a lot, it's both working great and highly appreciated. |
Excellent, I am happy to hear and thanks for reporting. |
@cjbrigato - I have added support for stdin (by simply allowing It will be available in the next release. |
Some users expect to be able to run
cli --arg param required_arg
in addition to the currently supportedcli required_arg --arg param
.catch_all
functionalityAny reasonable solution will probably require changing the serial filters here:
bashly/lib/bashly/views/command/parse_requirements.erb
Lines 11 to 13 in e8804a9
so that they just work together as one, probably something like this:
--flag
, add it to the${args[--flag]}
arrayarg
, add it to the${args[arg]}
array, where the arg name is shifted from the full args list.The text was updated successfully, but these errors were encountered: