Open thomask77 opened 5 months ago
Follow up:
I think split_arg_string
and its newly-enabled comment handling should also be used before handle_internal_commands
.
Otherwise :help
works, but :help # call internal help
does not.
I am the one who removed the ability to add comments in the prompt. and It's because that's how click parses it too. I just copied that function straight out from here
So, just to parse the args in the same way that click does, I have to do it.
Maybe you can alter the behaviour of handle_internal_commands
function to remove the comments before execution.
ok, now whats the behaviour that you want to expect from this utility @thomask77 ?
what are the right scenarios to include and exclude comments?
I'd say enabling comments to pass in as input for normal click commands seems fair
cuz the input can sometimes expect the #
character sometimes
do you have any other way to deal with this?
Hmm, ok.
I see that came from the built-in shell_completion.py part of click.
That's a special case, and parsing with lex.commenters = ""
is probably correct there.
Normally click does not parse (or see!) the raw command string, but only the args[] array. The comments are already removed by the shell.
But in case of click_repl, we are the shell and have to remove comments before invoking click.
When you do
myprogram foo bar # this is a comment
in bash
, myprogram only ever sees sys.argv = ["myprogram", "foo", "bar"]
.
The comment is stripped by the shell, and is invisible to click.
(If you want to pass a argument containing a #, normal shell escape rules apply. Use # or enclose in " " / ' '.)
click-repl should match this behavior, and also remove the comment before any further processing.
When feeding prepared scripts to click-repl, it would be useful to support # comments.
shlex already supports this feature, but click-repl explicitly disables it (why?):
As a workaround, I vendored click-repl and commented out that line.
Additionally, this needs a check to skip processing if the resulting args are empty: