

Show HN: clip – Embeddable, composable [c]ommand [l]ine [i]nterface [p]arsing - willyg302
https://github.com/willyg302/clip.py

======
cornstalks
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...

~~~
willyg302
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!

~~~
izolate
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.

------
joseph8th
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]

[1]
[https://docs.python.org/2/howto/argparse.html](https://docs.python.org/2/howto/argparse.html)

[2]
[https://github.com/joseph8th/shkeleton](https://github.com/joseph8th/shkeleton)

~~~
willyg302
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?

------
untitaker_
How is this different from click?

[http://click.pocoo.org/](http://click.pocoo.org/)

~~~
toyg
EpicDavi linked this doc:
[https://github.com/willyg302/clip.py/blob/master/docs/main.m...](https://github.com/willyg302/clip.py/blob/master/docs/main.md)

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

~~~
juanpabloaj
move doc file to

[https://github.com/willyg302/clip.py/blob/master/docs/index....](https://github.com/willyg302/clip.py/blob/master/docs/index.md)

------
EpicDavi
This project also has surprisingly pleasant documentation[1].

1\.
[https://github.com/willyg302/clip.py/blob/master/docs/main.m...](https://github.com/willyg302/clip.py/blob/master/docs/main.md)

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

~~~
willyg302
> _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](https://github.com/pickhardt/betty)

~~~
fiatjaf
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.

~~~
willyg302
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".

