Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

github.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

#11

Post by willyg302 »

fiatjaf wrote: post #6

Why don't we have CLI programs with complex parseable options, something that could only be parsed by a parser generator, but would seem more natural to write, instead of lots of --flags --and --options. Just thinking about it.

> complex parseable options, something that could only be parsed by a parser generator

Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options.

1. https://github.com/pickhardt/betty

Re: Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

#12

Post by juanpabloaj »

toyg wrote: post #7
untitaker_ wrote: post #5

How is this different from click? http://click.pocoo.org/

EpicDavi linked this doc: https://github.com/willyg302/clip.py/blob/master/docs/main.m... > For example, Click has integrations for fetching terminal dimensions and setting environment variables. This may be useful, but it also means trying to use Click for an embedded CLI (say, one running in a text editor communicating via websockets) is extremely difficult.

move doc file to

https://github.com/willyg302/clip.py/blob/master/docs/index....

Re: Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

#13

Post by izolate »

willyg302 wrote: post #9
cornstalks wrote: post #2

Seems neat, but to be honest, I had a really hard time reading the example because of all the encheferizer text. The funky, hard-to-read text is distracting me from understanding and appreciating the overall simplicity and elegance of things (in a kind of ironic way). But, aside from that, I'm coveting this right now as I hack away with adding new options to my C++ program...

You raise a fair point. The only reason I encheferized the readme example was to have a little fun with it, as one of its goals is to demonstrate help screens...but that ends up making the code look like a wall of text no matter what "language" the messages are in. Anyway, once I think of a better example I'll swap it in. Thanks for your input!

I pray for your sense of humor, and look fondly towards seeing those horridly childish examples removed.

This is quite an elegant piece of software, and your readme is doing it little service.

Re: Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

#14

Post by fiatjaf »

willyg302 wrote: post #11
fiatjaf wrote: post #6

Why don't we have CLI programs with complex parseable options, something that could only be parsed by a parser generator, but would seem more natural to write, instead of lots of --flags --and --options. Just thinking about it.

> complex parseable options, something that could only be parsed by a parser generator Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options. 1. https://github.com/pickhardt/b…

Are you just parsing the text and covering all those options? Or are you doing some sort of natural language processing?

I didn't meant something so abrangent, I meant something simpler. For example, `ls`:

Instead of `ls -l`, `ls complete` or `ls with metadata`.

Instead of `ls -L`, `ls following symlinks`.

Instead of `ls -a`, `ls all` or `ls with all`.

I don't remember exactly what I was thinking.

Re: Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing

#15

Post by willyg302 »

fiatjaf wrote: post #14
willyg302 wrote: post #11

Earlier quoted context omitted.

> complex parseable options, something that could only be parsed by a parser generator Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options. 1. https://github.com/pickhardt/b…

Are you just parsing the text and covering all those options? Or are you doing some sort of natural language processing? I didn't meant something so abrangent, I meant something simpler. For example, `ls`: Instead of `ls -l`, `ls complete` or `ls with metadata`. Instead of `ls -L`, `ls following symlinks`. Instead of `ls -a`, `ls all` or `ls with all`. I don't remember exactly what I was thinking.

I like this idea, but no, clip is about as simple as you can get. Direct greedy parsing one token at a time.

It seems like you could get something like your examples by doing option aliases, so typing "complete" or "metadata" would be parsed as `-l`. However even something this simple starts to complicate parsing quite a bit (e.g. where are the option boundaries?) especially if you allow multiple tokens in an alias, like "with all" --> `-a`.

And at the end of the day, it just helps to learn through repetition. I have no idea what the "plant" means in `netstat -plant`, but I know it generates the output I want. Similarly it's much easier to type `ls -latr` than "ls complete all sort oldest first".

Post reply on HN