4 ms·

I have a hard time imagining how we get out of the gravity well of CLI programs handling their own parsing. A tool I write has a use-case for understanding the

I have a hard time imagining how we get out of the gravity well of CLI programs handling their own parsing. A tool I write has a use-case for understanding the syntax of at least ~common CLI tools well enough to pick out args that will be other executables (sudo cat, find blah -exec...), so I have been idly pondering whether there's a humane, declarative, descriptive grammar that can express nearly all CLI interfaces. It's probably not worth the work for my case, but it might get to be more tractable if it was also an input for better completion, help, linting, etc. tools. Ideally something that drives enough all-around value that projects would start up streaming the grammars (and maybe adopting an associated parser?)

lgas 4y ago
You might find http://docopt.org/ http://docopt.org/ to be of interest. (It's available in many languages https://github.com/docopt https://github.com/docopt).
- abathur 4y ago
  Parsers designed for implementing CLI programs are generally too opinionated to handle ~strange commands. (In my terms I'd say it's a prescriptive parser as opposed to something that attempts to be flexible enough to describe nearly all existing CLIs).
  - ablob 4y ago
    Wouldn't it be easier to have a convenient library/parser for almost all of the use cases instead of an immensely complex catch-all solution? Having custom logic when required should almost always be less complex when such a ~strange command is to be implemented.
    - abathur 4y ago
      As I said, my usecase doesn't involve implementing the commands--it involves reliably identifying executables in the arguments to many different commands. I can't go rewrite awk, find, and sed with an opinionated cli module. I have to deal with the current reality. (you're roughly describing what I already do, and it scales poorly)
mschrage 4y ago
You might find Fig completion specs useful for this: https://github.com/withfig/autocomplete https://github.com/withfig/autocomplete
- abathur 4y ago
  Completions have in general been of interest, though the shell-specific completions I've looked at so far were all too dynamic. I'd forgotten all about Fig since I saw your launch post here last year, so thanks for reminder. (I don't think I had quite started to work on parsing specific external commands, yet, so it wouldn't have clicked at the time. Was still focused on just identifying the likely presence of exec in the executables.) Are you familiar with the parse code? Are you handling painful stuff like combined short flags with a trailing option? (If I ferreted out some of the more painful cases I've had to wrangle, I am curious if you'd have a gut sense of whether your approach handles it. Would you mind if I reach out? I am working on this for https://github.com/abathur/resholve https://github.com/abathur/resholve)

lgas 4y ago

You might find http://docopt.org/ http://docopt.org/ to be of interest. (It's available in many languages https://github.com/docopt https://github.com/docopt).

abathur 4y ago
Parsers designed for implementing CLI programs are generally too opinionated to handle ~strange commands. (In my terms I'd say it's a prescriptive parser as opposed to something that attempts to be flexible enough to describe nearly all existing CLIs).
- ablob 4y ago
  Wouldn't it be easier to have a convenient library/parser for almost all of the use cases instead of an immensely complex catch-all solution? Having custom logic when required should almost always be less complex when such a ~strange command is to be implemented.
  - abathur 4y ago
    As I said, my usecase doesn't involve implementing the commands--it involves reliably identifying executables in the arguments to many different commands. I can't go rewrite awk, find, and sed with an opinionated cli module. I have to deal with the current reality. (you're roughly describing what I already do, and it scales poorly)

mschrage 4y ago

You might find Fig completion specs useful for this: https://github.com/withfig/autocomplete https://github.com/withfig/autocomplete

abathur 4y ago
Completions have in general been of interest, though the shell-specific completions I've looked at so far were all too dynamic. I'd forgotten all about Fig since I saw your launch post here last year, so thanks for reminder. (I don't think I had quite started to work on parsing specific external commands, yet, so it wouldn't have clicked at the time. Was still focused on just identifying the likely presence of exec in the executables.) Are you familiar with the parse code? Are you handling painful stuff like combined short flags with a trailing option? (If I ferreted out some of the more painful cases I've had to wrangle, I am curious if you'd have a gut sense of whether your approach handles it. Would you mind if I reach out? I am working on this for https://github.com/abathur/resholve https://github.com/abathur/resholve)