6 ms·

Thanks for reviewing it. I definitely went into this with a 'let's start with something good and useful for as many commands as possible', so I haven't focused

by idank 13y ago

Thanks for reviewing it. I definitely went into this with a 'let's start with something good and useful for as many commands as possible', so I haven't focused on accuracy for those edge cases. But from what I played with it so far, results have been pretty good. Agree again on the pipe et al. support. It's not easy, hence why I haven't added this right out of the gate. I basically have to build a parser for bash, although I can probably get away with handling only a small subset of it that is interesting in this context, such as pipes, redirections, etc. I still have to figure out how to display multiple commands, because chunking them all in one page isn't going work visually. I'll be happy to hear more about turning this into a learning environment. It might not work for this particular tool, but maybe it can use the foundations.

deleted 13y ago
[deleted]
thangalin 13y ago
Hard to follow running 1024x768: http://i.imgur.com/rVVrZCc.png http://i.imgur.com/rVVrZCc.png
mtdewcmu 13y ago
Is it possible to use the parsing in this to generate autocomplete rules?
- idank 13y ago
  It's possible, but I'm not sure how robust it will be. There are a lot of heuristics being used to guess what the options are, if they expect an argument, etc. So when feeding it with a command that was typed by someone, which is most likely correct, it's fairly easy to look up each option in all the possibilities. Not to mention some commands have a very complicated set of rules (e.g. find), and the position of some options is context sensitive, which explainshell isn't (it could be, but that would require a lot of manual work). It's interesting because I had an idea once to do the opposite: see if explainshell could use completion files from bash/zsh/fish as another source of options besides the man page.
  - mtdewcmu 13y ago
    Completion scripts from bash are far too much of a kludge to extract information from. Most tools are written in C, and the standard way to parse options in C is with getopt(3) or getopt_long(3). I actually looked into searching the compiled binary for the getopt_long structure, but that wasn't so easy. Since these functions have information on all the possible options, it would be nice if there was a standard way to get them to spit out the option list.* See my reply to your comment in another thread. It would be a killer app to have better autocomplete support, but I can't offer assurance that it's feasible. * I had another idea: you could use ELF tricks (LD_PRELOAD) to load a different version of getopt/getopt_long that would spit out the specifications.
- JelteF 13y ago
  Fish shell does something like this. It's nice to start from, but there are definitely not enough on their own. Git for instance needs extra rules to complete branches and so forth. [1] http://fishshell.com/ http://fishshell.com/
  - mtdewcmu 13y ago
    It's about time someone made a shell for the 90s. That was a great decade. Heyyy, Macarena! If it is a replacement for bash, then I'm afraid I'm too attached to bash to give it up.

by idank 13y ago

deleted 13y ago

[deleted]

thangalin 13y ago

Hard to follow running 1024x768: http://i.imgur.com/rVVrZCc.png http://i.imgur.com/rVVrZCc.png

mtdewcmu 13y ago

Is it possible to use the parsing in this to generate autocomplete rules?

idank 13y ago
It's possible, but I'm not sure how robust it will be. There are a lot of heuristics being used to guess what the options are, if they expect an argument, etc. So when feeding it with a command that was typed by someone, which is most likely correct, it's fairly easy to look up each option in all the possibilities. Not to mention some commands have a very complicated set of rules (e.g. find), and the position of some options is context sensitive, which explainshell isn't (it could be, but that would require a lot of manual work). It's interesting because I had an idea once to do the opposite: see if explainshell could use completion files from bash/zsh/fish as another source of options besides the man page.
- mtdewcmu 13y ago
  Completion scripts from bash are far too much of a kludge to extract information from. Most tools are written in C, and the standard way to parse options in C is with getopt(3) or getopt_long(3). I actually looked into searching the compiled binary for the getopt_long structure, but that wasn't so easy. Since these functions have information on all the possible options, it would be nice if there was a standard way to get them to spit out the option list.* See my reply to your comment in another thread. It would be a killer app to have better autocomplete support, but I can't offer assurance that it's feasible. * I had another idea: you could use ELF tricks (LD_PRELOAD) to load a different version of getopt/getopt_long that would spit out the specifications.
JelteF 13y ago
Fish shell does something like this. It's nice to start from, but there are definitely not enough on their own. Git for instance needs extra rules to complete branches and so forth. [1] http://fishshell.com/ http://fishshell.com/
- mtdewcmu 13y ago
  It's about time someone made a shell for the 90s. That was a great decade. Heyyy, Macarena! If it is a replacement for bash, then I'm afraid I'm too attached to bash to give it up.