
Betty – English-like interface for the command line - jrpt
https://github.com/pickhardt/betty
======
the_af
I wonder if the author of Betty has taken a look at one of the existing Inform
([http://inform7.com](http://inform7.com)) interpreter variants used for
Interactive Fiction games (what we used to call "text adventures"). They have
progressed a lot since the old text adventures of yore, and are now capable of
parsing pretty complex English sentences (instead of just "take sword", you
can write "examine sword, then take it and give it to the wizard", and the
interpreter will even ask you about ambiguities, such as "which sword? the
magic sword or the long sword?").

Then again, I'm unsure if the precision needed from command line interfaces
can ever be improved with _natural_ language. Natural language is imprecise,
ambiguous, redundant, and confusing even to our human interlocutors. Why would
we want to interface with computers in English, instead of using a synthetic
and concise made-up language? I'm talking specifically about the command line,
which is for power users anyway.

(A perfectly valid answer is "because it was fun to write Betty, and that's
its own reward", of course).

~~~
jrpt
No, I wasn't aware of that, but that is interesting.

Betty just grew out of my cheat sheet of commands. I was tired of repeatedly
looking up things in my cheat sheet or Google, and decided to make this.

The current project has a limited number of commands, but I am hoping that by
making it public, others will issue pull requests with things they'd want to
use.

Its current state is command line only, which is for power users. But thinking
ahead, on the roadmap I wrote that by the time it reaches v1.0, I'd like it to
be extensible. This means it can be used from text-to-speech apps or whatever.
Some futuristic use cases: I'm sitting on my bed, with my computer on my desk,
and say "Betty: next song" and it just works. Or I'm running on my treadmill,
talking aloud: I'd say "Betty: open the New York Times in Chrome" then "Betty:
read me this article" and it just works. That'd be cool. I don't know
specifically how to do everything I'd want to do, but those are the sorts of
far future things that would be cool. In its current implementation, it's
mainly for not having to keep looking up commands or options.

~~~
the_af
That would be cool indeed and I hope my comment didn't sound too negative. And
you should definitely take a look at Inform (and similar), it's amazing what
they can do. I think some interpreters are open source (edit: it seems it's
not, I remembered incorrectly).

~~~
rolux
Ironically, with version 7, Inform itself switched to natural language syntax.
The following is valid Inform 7 source code:

`The iron-barred gate is a door. It is north of the Drawbridge and south of
the Entrance Hall. It is closed and openable. Before entering the castle, try
entering the gate instead. Before going inside in the Drawbridge, try going
north instead. Understand "door" as the gate.`

However, what makes a command like "examine sword, then take it and give it to
the wizard" complex is not the parsing, but the world model. What if examining
the sword reveals an engraving saying "Never hand this to a wizard"? What
happens to giving if taking fails? What if the wizard himself is holding the
sword? What if he attacks anyone holding a weapon? Etc.

Writing a natural language command line interface seems a lot more
straightforward.

~~~
e12e
Unfortunately, as I understand it, while the "old" v6 toolset is open, the
"in" tool that takes "regular" text and turns it into v6 "code" is gratis, but
not open sourced:

[https://groups.google.com/forum/#!topic/rec.arts.int-
fiction...](https://groups.google.com/forum/#!topic/rec.arts.int-
fiction/PuQHYwtX77c\[1-25-false\])

Some more on how inform7 differs from more traditional interactive fiction
systems:

[http://www.onlamp.com/pub/a/onlamp/2006/06/08/inside-
inform-...](http://www.onlamp.com/pub/a/onlamp/2006/06/08/inside-
inform-7.html)

As for this tool: I like it. I like the idea that it's simple, and that the
author didn't let details like it being difficult to do "well" or "better"
stand in his way. I've thought along the same lines many times, not so much
"how did I do _ (solution often involves awk, sort, uniq et al) -- I'm too
familiar with the command line for that, but rather: Jeez, you've got a smart
phone. The _one_ guaranteed interface that works is audio in/out. How hard
could it be to deploy solid limited domain voice control coupled with a dead
simple state-machine for doing stuff like "next song", "stop", "play", "accept
call".

I wonder if these projects (there must have been projects, right, ever since
the first uptake of mp3s) get the first part working, then some moron suggests
that the user will expect to be able to do "play song such-and-such by such-
and-such" \-- and then it's no longer (strictly) limited domain, and that
doesn't work, so the scrap the whole thing.

[edit: Some more on "newstyle" inform vs traditional IF:] "A Comparison of
TADS 3 and Inform 7"
[http://brasslantern.org/writers/iftheory/tads3andi7.html](http://brasslantern.org/writers/iftheory/tads3andi7.html)

~~~
llamataboot
Inform was my very first programming language. Now that I code in Ruby all
day, I'd probably find something like TADS less frustration prone, but Inform
is incredibly powerful for its domain.

------
sytelus
Every natural language interface eventually will be required to generate a new
program. For example, if you say my parser supports query like "count number
of words in file X", someone would want to issue a queries like "count number
of words starting with character a and at most length 3 in file X" and so on.

Natural language interfaces eventually fall on its face not because parsing is
really hard but rather because after you parse, how do you generate a program
on the fly to solve the user's problem.

~~~
mallamanis
It is indeed a hard problem, but there is some research going on in this area
[http://people.csail.mit.edu/nkushman/papers/naacl2013.pdf](http://people.csail.mit.edu/nkushman/papers/naacl2013.pdf)

and the application is definitely worth it, because it lowers the barrier for
doing "complicated" stuff for people that are not very computer-savvy

------
FriedPickles
Crazier alternative:

1) Install howdoi
[https://github.com/gleitz/howdoi](https://github.com/gleitz/howdoi)

2) Write commands like the following (all work as expected):

    
    
        howdoi get time in bash | sh
        howdoi clear bash | sh
        howdoi find current user bash | sh
        howdoi restart computer bash | sh
        howdoi fork bomb | sh
    

#YOLO

~~~
e12e
It might be worth mentioning that howdoi is just a wrapper around a google
(essentially a "I'm feeling luck"-search as far as I can tell)?

It's hardly the same as a curated set of specialized pipes. Nor does it work
offline (howdoi configure eth0/enable wireless...).

~~~
TeMPOraL
It actually uses StackOverflow.

~~~
e12e
Indeed it does, I only read to around:

    
    
        SEARCH_URL = 'https://www.google.com/search?q=site:{0}%20{1}'
    

and didn't look much further.

------
omarhegazy
Really interesting program, although, as Andrew has said, seems kinda limited.
That's not your fault at all; any early project will seem limited in scope.
Given some popularity and extra effort, something like this could be the Siri
of the command line.

Which gets me thinking -- is stuff like Siri and Google Now really just like
this? Core set of pre-set commands surrounded by regex magic to recognize said
pre-set commands? Interesting.

Begs the question : is it possible, using current knowledge in machine
learning and NLP, to create a English-like interface for
#{some_device_or_program_here} that _learns and self-develops_ the English
commands from the user? Sort of like how Bayesian spam filters
([http://www.paulgraham.com/spam.html](http://www.paulgraham.com/spam.html))
don't have core preset hardcoded set of Spam-Related Words and classify them
accordingly, but instead takes an initial corpus and then learns and self-
develops from the user after that.

~~~
e12e
I think having a prefix (be that "betty" "b" and/or some "mode" for your
shell) that signals you want to use natural language (with all it's ambiguity)
is a good idea. The zsh way of suggesting "did you mean" rather than simply
erroring with "command not found/invalid syntax" drives _me_ nuts -- but a lot
of people seem like it. Having a prefix allows you more freedom at "learning"
\-- ambiguity isn't so terrible if the user expects it (and the simple idea of
just listing alternatives that betty uses seems like a great interface. Not as
sexy as "I'm feeling lucky"-style (super-)high scoring wins, middling scores
ties and asks user to pick -- but I think it may win on the principle of least
surprise).

Anyway, it does seem that most proof-of-concept voice-control (as opposed to
text-controlled) systems use a prefix too "siri"/"glass"/<microsoft had one,
can't remember which, also they have "xbox". The idea is that if the mic is
always on, you don't want your drones to blow something up, just because you
jokingly told a friend "kill it with fire" in a voice call. Context is hard to
get right for such systems, I expect the kinetic and similar systems can do
better (if user looks at computer, listen. If user is already speaking "in
conversation with" to computer, listen. Otherwise ignore, unless user asks for
computer by name).

As for you question, I think it should be relatively easy to train, say a
music-player app to understand stuff like "next song", "accept call", "repeat"
\-- in _any_ language, using simple statistical methods. Not sure how far you
could take it though (example, dictation software still makes (AFAIK) enough
errors that it's not really a viable option if the user already can type
reasonably well (or hire an actual stenographer)).

~~~
omarhegazy
Stuff like "next song", "accept call", etc. can be done with extensive
knowledge in machine learning and some clever work.

The really tough bits will be stuff like,

"Siri, check if PBS Idea Channel has uploaded any new videos, please."

How will Siri know you mean the YouTube app? How will Siri know what "check if
X has uploaded any new videos" means? How will Siri know you mean "PBS Idea
Channel" and not the channel called "PBS Idea"?

------
roeme
Other than being fun; I can't quite see the benefit of making my shell more
verbose. I'm sure I am not the only one who can get by with the regular
commands through mnemonics.

And to further my point; if this was such a good idea, then why has nobody
aliased 'ls' to _list_ , 'cp' to _copy_ , (etc.)? Or, while we're at it, _'
list files'_, or _' list files in current directory'_. Maybe someone has and I
just didn't meet them yet.

I do see the point of a programming language to be a bit more verbose, since
it makes sharing between humans easier, as understanding old codebases – but
even there, people are split (Java is too verbose! Ruby is natural! Lisp is
too much abbreviated! etc.). But _using_ a shell, issuing _commands_ , is
fundamentally different to _programming_ , in my opinion. Consider the analogy
of a crane (just to avoid cars for once), what would you prefer: Waving your
finger around in thin air, or using levers? And before you answer that: while
the former seems way more cool, it doesn't work well. Getting rid of
mechanical controls has been tried experimentally by the Air force (I read
that back in the 90's; sorry no link to a source now): They were able to
interpret commands from the pilots brainwaves, but manual control was
_consistently_ faster. We humans just evolved this way: _Thinking_ of moving a
plane into particular direction is slower than moving your hand accordingly to
yank a stick – it seems to have a higher more mental load for us. Do you
picture your arm moving your mouse? I bet you "just do".

But I digress; though the fundamentals in play are the same. My fingers are
fast; why should I slow down the whole thing by making them type more?

Of course, a shell using of single-letter commands would be equally useless to
an overly verbose shell. The sweet spot, in the end, might be a personal
preference and dependent of daily usage and experience. In my case, that's a
bit more than the POSIX command set, and – to exaggerate a bit – not writing
essays on the command line.

~~~
area51org
It becomes interesting when you can tell Betty to do things you don't
otherwise know how to do. (How do you tell iTunes to skip this song from the
cmd line? I don't know, and I'm too lazy to look it up.)

~~~
saraid216
Do you mean skip it once, or skip it forever?

The first is really an "advance to next track" command.

The latter is a "mark current song as Never Play and advance to next track".

I'd be surprised if there was any kind of interface with iTunes that doesn't
have at least one of those capabilities.

------
ejain
Natural language interfaces can be _very_ frustrating when they (inevitably)
don't recognize (or worse, misinterpret) your input... I'd rather have
commands that are easy to remember (i.e. simple and consist).

------
andrewguenther
A cute tool, but seems incredibly limited. Why would I use any of these
commands more than once if I can just alias them? While some of them might be
useful I really just don't see myself using a tool like this.

~~~
singularity2001
And just for the kicks:

function genie(){ query=`printf "%s+" $@` echo $query result=`curl -s
"[https://weannie.pannous.com/api?out=simple&input=$query"`](https://weannie.pannous.com/api?out=simple&input=$query"`)
echo $result say $result 2>/dev/null } alias hey=genie alias how="genie how"
alias what="genie what" alias when="genie when"

me:~$ what is the root of pi It is approximately 1.7725

me:~$ how old is obama Barack Obama is 52 years old

~~~
hidden-markov
A PR implementing that for Betty:
[https://github.com/pickhardt/betty/pull/4](https://github.com/pickhardt/betty/pull/4)

------
rawland
That's great. However, I don't see an end to capture all the ambiguity of
language and especially misspellings... can this be contained in a reasonably
fast running script?

    
    
      ~/tmp betty my ip
      Betty: Sorry, I don't understand.
      ~/tmp betty my ip adress
      Betty: Sorry, I don't understand.
      ~/tmp betty whats my ip address
      Betty: Running curl ifconfig.me

------
jeffreyrogers
This is an interesting idea, but I'm not sure it has much use outside of proof
of concept. Most people don't need to use the command line, and those who do
don't find it that difficult.

In fact, for the most part the command line is very usable once you've learned
the philosophy behind it. I remember reading something about the BSD flavors
of UNIX along the lines of "BSD is very user friendly, just not for
inexperienced users". I see the command line as being similar. It's very
powerful when you understand it, but a bit opaque when you're learning it.
Fortunately, you can learn the basics in an afternoon.

Now one useful aspect of this is that it makes commands that would require a
long command line much simpler than they would otherwise be. However, I find
that whenever I have a long command line that I use repeatedly I just write an
alias for it and add it to my .zsh-aliases file. I like this solution better
because it is more customizable for my workflow.

~~~
e12e
Well, an argument could be made for having the alias-file be something like:

    
    
        alias ll="ls -l"
          doc = """List files -- long list format"""
          natural_match = "list all files long size date owner group"
    

And have:

    
    
        "list all files by size"
    

match this (as betty does now: running ll "docstring". Then, when you realize
that "list all files by size", really is "ls --sort=size", possibly with "-l",
you could just add another definition:

    
    
        alias lss="ls -l --sort=size"
          doc = """List files -- sorted by size, long list format"""
          natural_match = "list all files sort by size long format"
          natural_exact_match "list all files by size"
    

And now have:

    
    
        "list all files by size"
    

Score higher for lss than for ll (the scoring function is assumed to be some
combination of tag count, proximit match, substring match etc, a so-called
hard problem, but only needs to match over defined aliases -- and trying hard
to first match the "exact_match" part...).

Of course, it should all be paired by a define-command or something that
autmatically saves these monstrosties to a file or other db. So that you could
do:

    
    
         # Lots of head scratching and experimentation, until:
         nmcli dev wifi list |sort -k8 -n # list wifi access points by
                                          # signal strength
    
         # define prev as "list wifi access points by signal strength"
         > displays commmand and prompt for tags etc, then on "y" at y/n
           prompt saves definition to "alias" file.
    
    

Come to think of it, it's a little like mandating/recommending users to
_document_ their aliases, and to have the shell automatically suggest from the
docstrings. I guess zsh actually does a bit of this already (I'm still
sticking with bash, it's gotten good enough for me over the years, and I'm
always terrified by something, that if it isn't posix/ksh also isn't bash --
as that just makes scripts brittle...).

------
eschaton
Seems like this could be handled more like the Symbolics Genera command line,
which offered extensible intelligent commands with context-sensitive
completions. Here's a demo by Kalman Reti:
[http://youtu.be/o4-YnLpLgtk](http://youtu.be/o4-YnLpLgtk)

------
borplk
Interesting project. I know for us geeks the short obscure commands are
sometimes easier but something like this can ease people into using command
line more.

I applaud the author because typically I don't have the courage to even
attempt solving problems like this. And I wonder what the author is going to
do about this.

Because well ... natural-language processing just isn't there yet, you can
kind of "fake" it a bit by looking for keywords and patterns and regex but it
only goes so far.

So beyond a certain point, you end up needing to solve the natural-language
processing problem first, so that you can then build Betty.

------
codereflection
Betty looks pretty interesting. Adding tab completion would certainly cut down
on the amount of typing with the length of the commands. Do the commands also
accept short variants? Such as i for iTunes?

------
hisham_hm
Why are all computerized natural-language "assistants" all modeled as female?
(Siri, Cortana, Betty...) A remnant of the view of women's role as
"secretaries"?

It's interesting to see that this applies to real-world products, which are
still kind of "dumb" or single-minded (as in default voices for GPS navigation
assistants), while in fiction, when computers are smarter than its owner (HAL,
Jarvis) they more are often than not represented as male.

~~~
HCIdivision17
I think you can find quite a few counter examples of a female AI, not least of
which Cortana. It's possible to imagine S'Jet as an example, though perhaps
much closer to Transcendence (movie) than AI.

Really, I think it simply has a lot to do with the voice. I'll be darned if I
can recall the source, but it seems that women can usually be understood more
clearly and easily than men; that claim may be only over a lossy channel, but
it seems to jive with my experience (listening to podcasts on a motorcycle,
women tend to be easier to make out over the noise, and even Google maps'
female voice is clear over a highway's roar).

------
ebbv
This seems like a recipe for disaster.

When you're at a command prompt you should always know exactly what the
command you're inputting is going to do. Since Betty necessarily obfuscates
your command this seems like a good way for unintended consequences.

The obvious solution to that is make it so Betty never does anything that
actually matters. So then the question is; why bother with Betty at all?

------
thrayfounder
That there is masterful copy.

I'll be honest, I have a general software test called "StonerTesting" \- if
you're high as fuck a lot of your cognitive function is distorted, so
successfully using a piece of software (even its website) means you're
software is in fact quite easy to use.

I'm thinking of offering it as a service.

------
thekonqueror
Chance for my Plug: I'm using similar approach with cloud management at
[http://webservice.management](http://webservice.management). It allows you to
manage VMs and run tasks across them in english. (Create a small vm with
node.js or build lamp stack on vm1 and so on)

------
chanced
Upon seeing the list of commands, I immediately thought "this is great! I
could alias betty to b and then maybe a few more aliases here and there. I
could take "betty next song" and make it 'b n s'!"

and then went "oooooh, so that's how this all started."

------
epynonymous
isnt the whole idea of a command line for impatient little people like myself
that dislike guis and inefficiency? this sort of defeats the whole purpose,
i'm now typing sentences instead of shortcuts

~~~
heyimwill
To some people this might be an easier and more efficient way to wrap their
head around the CLI.

------
Goosey
Is it compatible with fish shell?

edit: answering my own question, it seems to work just fine

------
d0ugie
Between this and bropages Linux is finally taking shape as a viable contender
to MSDOS! :)

Curious how many man hours have been put into Betty so far. Good work
pickhardt, looking forward to taking this for a spin. Hope you put in some
umask command support in this, I keep screwing that up...

------
billrobertson42
COBOL was supposed to be English-like too wasn't it?

------
elwell
CLI in Ruby, ok.

------
kelmop
I like this idea a lot. But why on earth it is written in ruby?! - I know the
answer and it is "ok". But it is probably the reason why it won't never gain
huge momentum, prove me wrong :)

~~~
AaronBBrown
What language would you write it in?

~~~
kelmop
c :)

