Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing
github.comSeems 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...
I was thinking the exact same thing. I had to read the text out loud in a European chef accent to understand what it was talking about. It really obfuscated the underlying meaning/simplicity of it for me.
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.
I like it! Simplest use case it saves on boilerplate required by argparse. [1] But the potential for embedded apps is the real draw for me. I have a CLI app I'd like to provide a notebook GUI for... This would be perfect. Just swap out argparse for clip.py, write the embed script and the GUI can use the same methods. No need to code additional logic to handle GUI widgets.
I wonder how hard it would be to make my 'shkeleton' CLI parser embeddable -- it's basically argparse for bash scripting right now. [2]
shkeleton looks pretty neat too! Amazing that it's 100% bash, as someone who shies away from bash scripting for all but the simplest scripts I can't imagine recreating argparse in it :)
Well, my definition of "embeddable" is a very loose one. All you really need to be able to do is allow the user to specify in/out/err streams, so that they could be anything: a log file, a socket, a Python function, etc. So maybe keep a var for each of these and redirect the echos to them?
How is this different from click?
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....
This project also has surprisingly pleasant documentation[1].
1. https://github.com/willyg302/clip.py/blob/master/docs/main.m...
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.
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".