
Vorpal, a framework for building CLIs - fidbit
http://vorpal.js.org/#
======
ianbicking
If I was making an interactive command line, I think I'd want to do it all in
shell. Let's say it's a CLI that interacts with a remote server, then I might
have a "script" that "starts" a custom CLI by doing:

    
    
        #!/usr/bin/env bash
        export REMOTE_ADDR="$1"
        export PATH="$(dirname $0)/commands:$PATH"
        export PS1='service:\$ '
        bash
    

Now you do something like:

    
    
        $ server-cli https://myservice.com
        service:$ which upload
        /path/to/server-cli/commands/upload
        $ upload ./my-file.png
        uploading.......
    

All you are doing here is adding all your custom commands (which are just
command line applications), and starting up the CLI by giving it some context
of some sort. All I have here is $REMOTE_ADDR (which by convention a command
like upload would read), but you could have auth or whatever.

Along with this, you get a pretty workable programming language (shell),
access to the local environment, access to the "standard library" of commands
you know, and so on.

~~~
dc2
True. Though in Node, you can make calls to standard programs, so it can act
pretty seamlessly. And there's already a lot of direction towards supporting a
lot of familiar methods and more. Like this:
[https://www.npmjs.com/package/cash](https://www.npmjs.com/package/cash)

~~~
dc2
* Cash isn't released yet - that's why there's no GH repo. That's my next pjt :)

------
gcb0
ah, the javascript developer mindset applied to CLI development.

Start from scratch just because you don't want to read the manual of the right
technology, convince lots of people to adopt with a cool site, spend the next
5 years updating your project to get to 10% of the 20yr old projects you
ignored.

disclaimer: mostly javascript developer nowadays. but salty.

~~~
emgee3
But a benefit might be cross-platform compatibility seeing as some OSes don't
come with, say, grep out of the box. While you could use the native tools,
there could be some benefit to writing your own to do exactly what you want
consistently.

I don't really disagree with you, but just pointing out there is some benefit
to writing one's own CLI.

~~~
ufo
I think its easier to install cygwin than replace all the command line tools I
am used to with Javascript equivalents.

~~~
benaiah
Having installed cygwin, I’m not so sure. :P

~~~
emgee3
Truth

------
woodruffw
Something about imitating the semantics of a UNIX shell in JavaScript doesn't
sit well with me.

~~~
giancarlostoro
I guess if you're building a CLI intensive application in node to begin with
then this library seems like a pretty nifty way to do it. I've used plenty of
CLI tools that don't offer auto-complete where it really would be handy to
see.

~~~
woodruffw
I suppose so. My big concern is that this will lead of a lot of faux-shells
with relatively few syntactic similarities.

It's a personal preference, but I'd much prefer my programs (node or
otherwise) treat the shell like the first class citizen it is and use it to
its fullest extent.

~~~
s_kilk
* I accidentally downvoted you while trying to upvote.

~~~
woodruffw
It's the thought that matters ;)

------
tantalor
This looks more like a complete shell replacement than a general-purpose CLI
builder.

~~~
giancarlostoro
I agree, I was expecting something like ncurses or something

------
dc2
Author of Vorpal here. You can ask me Qs if you'd like.

~~~
toupeira
Coming from other languages it's very confusing what this library does
exactly. The screenshots make it look like a full shell, but looking closer it
seems to be more of a high-level API that combines readline and optparse
functionality. It might be helpful to split up these parts and explain how
they improve on using the builtin NodeJS readline module and something like
optparse-js.

Also, a question about piping: in your example the "say" command is hard-coded
to use the argument called "words", and the "reverse" command is hard-coded to
read from standard input. This seems very limited compared to piping in a real
shell, shouldn't each command receive a string/array of input and return
output so they can be piped to each other without having to know about it?

~~~
dc2
I get you. Yes, it does combined readline and optparse-type functionality.
It's similar to Commander.js, with the exception that you have the option of
staying in the "shell" after the first command executes, and then it is its
own environment with its own commands.

On piping, I hard coded those to keep it short. Every single command can
receive "args.stdin", which is a stdin stream from previous commands. To pipe
out, the "this.log" command does all of the heavy lifting.

So all you would need to do is expect both "args.stdin" and "args.words" \-
that would cover input both from a directly executed command as well as stdin.
This works very well in practice.

------
sotojuan
For those who want to make simpler Node CLIs, check out meow[1].

[1]
[https://github.com/sindresorhus/meow](https://github.com/sindresorhus/meow)

~~~
dc2
Yes, Meow is an excellent tool.

------
realworldview
Immersive command line applications. I've already booked my seat on the next
intergalactic shuttle.

------
pjmlp
> The command-line is awesome

Actually, a REPL Xerox style is awesome, a pure UNIX style CLI not much.

