Doesn’t this seem dangerous? If one doesn’t know what a tool’s command line options do (as is given here), trying some unknown options seems to me dangerous, whether manually or, worse, using a tool to try several in quick succession, likely not giving the operator much chance to intervene to stop the next trial run from making things worse.
I see three ways halp foo could go wrong:
foo could have a flag -h, -H, -v, or -V that does something unwanted.
foo could ignore unknown flags, or all arguments, and, by default, do something unwanted.
foo help could interpret the argument as something other than a subcommand and do something unwanted, though I’m failing to think of any risks that seem less unlikely than deleting an irreplaceable file that for some reason was named “help”.
Good point, however, same risks exist when you manually try to run foo --help or an unknown argument. halp simply tries the automate the process of trying out different flags/arguments by hand. The foo in question might have malicious behavior attached to these arguments in both cases.
I had the same thought (that this probably isn’t universally safe) when I first saw this (on reddit?) but I waffled about bringing it up.
There’s certainly risk, but I agree that a confused human is roughly as likely to trigger it. A related (but less serious) risk is executables that’ll only anticipate stdin and just block without input.
I can think of a few ways to mitigate these:
try man/info before flags to the executable
keep track of problematic commands and have an exception to keep them from being an ongoing problem
figure out if there are ~reliable heuristics for when an executable is likely to fall into this category
build a collection/database of executable Metadata that indicates when these are known to be usable and act conservatively in the absence of this information
I have an MVP doing something like #3 for a different argument problem I ran into w/ https://github.com/abathur/resholve. Basically: resholve wants to block if there is a decent chance that unrecognized executables are present in a shell script. Certainty is hard, but I found reasonable success using YARA to separate ~safe executables with no known exec API use from those that use any such API. Extremely crude, and leaves a lot of false positives, but it mostly meets the safety I want to prioritize.
That said, there might be some common cause on #4. I would certainly prefer to have good static definitions that enable resholve to parse and identify commands/executables in the arguments to other commands. Such definitions might also flag built-in help options.
You might also be able be able to lean on the autocomplete definitions Fig uses. They aren’t high-fidelity enough for resholve, but they might more reliably identify help/version flags? (these are in https://github.com/withfig/autocomplete)
Oh, I wasn’t thinking of the command being outright malicious, merely of its interpreting one of -h, -H, -v, or -V as something that causes annoyance or data loss, or interpreting help as a path. I would expect --help to be safe unless the command silently ignores unknown flags, in which case a command like, say, reboot or poweroff could be a problem if one thinks it has flags and it actually doesn’t. I imagine that one often knows a command has a --help or -h option even if one doesn’t remember its other options (like in your demonstration, I certainly don’t know all Vim’s options), and often one knows a command won’t do anything damaging regardless of what options it is passed; otherwise, I guess, man is the safe approach (or cht.sh, which I hadn’t seen).
This is also a feature by default in Fish shell - when you go to enter arguments, it’ll print the arguments to a command and their description from the manual or help page in a navigable list format.
From the gifs on the page halp tries different combinations of -v, -h, --help, etc… until help text (any text?) is printed, or it’s exhausted the usual options.
You could call that library for the case where the lookup fails to help them diagnose that issue.
In general I like the idea of my tools giving me more context when things fail. Instead of simple “could not find file” why not take the next step or two I might take when debugging like list the files in the directory or give a “closest spelling” suggestion, highlight differences in file case etc.
Doesn’t this seem dangerous? If one doesn’t know what a tool’s command line options do (as is given here), trying some unknown options seems to me dangerous, whether manually or, worse, using a tool to try several in quick succession, likely not giving the operator much chance to intervene to stop the next trial run from making things worse.
I see three ways
halp foocould go wrong:foocould have a flag-h,-H,-v, or-Vthat does something unwanted.foocould ignore unknown flags, or all arguments, and, by default, do something unwanted.foo helpcould interpret the argument as something other than a subcommand and do something unwanted, though I’m failing to think of any risks that seem less unlikely than deleting an irreplaceable file that for some reason was named “help”.Good point, however, same risks exist when you manually try to run
foo --helpor an unknown argument.halpsimply tries the automate the process of trying out different flags/arguments by hand. Thefooin question might have malicious behavior attached to these arguments in both cases.I had the same thought (that this probably isn’t universally safe) when I first saw this (on reddit?) but I waffled about bringing it up.
There’s certainly risk, but I agree that a confused human is roughly as likely to trigger it. A related (but less serious) risk is executables that’ll only anticipate stdin and just block without input.
I can think of a few ways to mitigate these:
I have an MVP doing something like #3 for a different argument problem I ran into w/ https://github.com/abathur/resholve. Basically: resholve wants to block if there is a decent chance that unrecognized executables are present in a shell script. Certainty is hard, but I found reasonable success using YARA to separate ~safe executables with no known exec API use from those that use any such API. Extremely crude, and leaves a lot of false positives, but it mostly meets the safety I want to prioritize.
That said, there might be some common cause on #4. I would certainly prefer to have good static definitions that enable resholve to parse and identify commands/executables in the arguments to other commands. Such definitions might also flag built-in help options.
You might also be able be able to lean on the autocomplete definitions Fig uses. They aren’t high-fidelity enough for resholve, but they might more reliably identify help/version flags? (these are in https://github.com/withfig/autocomplete)
Oh, I wasn’t thinking of the command being outright malicious, merely of its interpreting one of
-h,-H,-v, or-Vas something that causes annoyance or data loss, or interpretinghelpas a path. I would expect--helpto be safe unless the command silently ignores unknown flags, in which case a command like, say,rebootorpoweroffcould be a problem if one thinks it has flags and it actually doesn’t. I imagine that one often knows a command has a--helpor-hoption even if one doesn’t remember its other options (like in your demonstration, I certainly don’t know all Vim’s options), and often one knows a command won’t do anything damaging regardless of what options it is passed; otherwise, I guess,manis the safe approach (orcht.sh, which I hadn’t seen).BSD tools taught me to use manual pages instead, due to the lack of an help option.
Interesting.
This is also a feature by default in Fish shell - when you go to enter arguments, it’ll print the arguments to a command and their description from the manual or help page in a navigable list format.
I think this just finds the
-horhelpflag?From the gifs on the page
halptries different combinations of-v,-h,--help, etc… until help text (any text?) is printed, or it’s exhausted the usual options.I like the idea. I wrote this CLI (and library) for helping to diagnose errors stemming from failed path lookup: https://github.com/schneems/which_problem
You could call that library for the case where the lookup fails to help them diagnose that issue.
In general I like the idea of my tools giving me more context when things fail. Instead of simple “could not find file” why not take the next step or two I might take when debugging like list the files in the directory or give a “closest spelling” suggestion, highlight differences in file case etc.