1. 14

  2. 9

    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:

    1. foo could have a flag -h, -H, -v, or -V that does something unwanted.

    2. foo could ignore unknown flags, or all arguments, and, by default, do something unwanted.

    3. 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”.

    1. 2

      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.

      1. 1

        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:

        1. try man/info before flags to the executable
        2. keep track of problematic commands and have an exception to keep them from being an ongoing problem
        3. figure out if there are ~reliable heuristics for when an executable is likely to fall into this category
        4. 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)

        1. 1

          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).

      2. 5

        BSD tools taught me to use manual pages instead, due to the lack of an help option.

        1. 1


        2. 2

          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.

          1. 1

            I think this just finds the -h or help flag?

            1. 1

              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.

          2. 1

            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.