[HN Gopher] Show HN: Ell - A command-line interface for LLMs wri...
___________________________________________________________________
Show HN: Ell - A command-line interface for LLMs written in Bash
Hi HN! I've created a CLI tool called "ell" that allows you to
interact with LLMs directly from your terminal. Designed with the
Unix philosophy in mind, ell is simple, modular, and extensible.
You can easily pipe input and output to integrate with other tools.
Its templates and hook-based plugins enable you to customize and
extend its functionality to suit any needs. Check out the README
for usage instructions and examples. I developed this tool because
existing solutions often felt too heavy, with many dependencies, or
they weren't friendly to piping and customization. I, on the
contrary, wrote in almost pure Bash with least dependencies.
Additionally, I found a lack of tools that could read past terminal
output as context. Imagine encountering an issue in your terminal
and being able to directly ask an LLM for help with a simple
command--this is now possible with ell (see the demo video). Known
limitations: - To maintain simplicity and efficiency, jq is used
for JSON parsing. - Cannot avoid curl to sending HTTPS requests.
If only there were SSL / TLS support in `/dev/tcp/`! - Perl is
used to handle terminal escape sequences because regex in Bash does
not support looking around. - Markdown syntax highlighting is not
perfect due to the need for streaming output. It relies on a simple
state machine instead of a full parser, which may produce falsy
results. - Other known issues are listed in Github Issues. Please
help add more! I welcome any criticism and suggestions, whether
it's about the idea or code!
Author : simonmysun
Score : 148 points
Date : 2024-08-02 11:55 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mherrmann wrote:
| Cool. The link to "Risks" in the README is broken.
|
| What I would love: `ell -r` automatically, and an alias `fix`
| that proposes a fix, including making changes to a file. For
| example, say I have a typo in main.cc and do `gcc main.cc`. When
| I run `fix`, I want ell to propose a fix in the file with a diff.
| If I accept, it should make that change. Then it should propose
| running `gcc` again - and run it for me if I accept.
| Zambyte wrote:
| Regarding running ell -r automatically, you can just add it to
| your .bashrc
| mherrmann wrote:
| Yup. But the rest of the functionality is missing, I think.
| simonmysun wrote:
| > The link to "Risks" in the README is broken.
|
| Fixed. Thanks for pointing out!
|
| > `ell -r` automatically, and an alias `fix` that proposes a
| fix, including making changes to a file.
|
| Good idea! `ell -r` can be added to `.bashrc`, but I'm not sure
| if it will conflict users' original configurations or there
| will be other issues. Except confirming a patch, I think it is
| feasible with template and plugins, but making actuall changes
| is challenging for me, both techinology wise and user interface
| design wise. I will try to figure out what can be possible
| hacker-l wrote:
| Hi, they're also trying to do something similar with shell. I'm
| not sure who's better. [demo](https://x-cmd.com/mod/gemini)
| [source code](https://github.com/x-cmd/x-cmd/blob/main/mod/gemini
| /lib/main)
| simonmysun wrote:
| Cool! This is looks a lot fancier.
|
| EDIT: I was wrong. Ignore the next paragraph.
|
| ~~I haven't looked into details but it looks reading from
| somewhere like `.bash_history`. That's a good idea to get user
| input from. But as far as I learned, it cannot use the terminal
| ouput as context. I might be wrong. I should read more about
| its implementation.~~
|
| It turns out it cannot make use of terminal output. But I like
| it that it use awk to process the response. I might also be
| able to use awk to get rid of the dependencies of jq and perl.
| Thank you for letting me know this.
|
| I will add it in the related projects chapter in README
| curry798 wrote:
| It looks beautiful and has many features, why are there so few
| star?
| simonmysun wrote:
| I also wonder. It didn't appear in my search because, I
| guess, it has too many features and the feature I want to
| search has a relatively low weight. I also searched x-cmd on
| HN but there aren't many positive comments... I would expect
| it's more popular on HN because it's written in POSIX shell
| and awk.
| mvavassori wrote:
| I don't know why i keep getting the error:
|
| "FATAL Template not found: ~/.ellrc.d/templates/default-
| openai.json"
|
| after having cloned the repo in my home directory and created the
| configuration file in .ellrc in my home directory. Don't know,
| probably i'm doing something wrong... I'm new to bash projects,
| why does it search for the templates in .ellrc.d? what's the .d
| part? I don't understand.
| simonmysun wrote:
| Oh sorry that's my bad. The target clone path did not match the
| default value of template path.
|
| Please make sure you either clone the repo to `~/.ellrc.d` or
| set ELL_TEMPLATE_PATH to where you store your templates (with
| `/` at the end) .
| mvavassori wrote:
| Thank you, i always assume there's some magic part that goes
| on behind the scenes which i don't understand, especially in
| things i'm not familiar with... In fact it was just a path
| mismatch as the error suggested.
| simonmysun wrote:
| You are welcome. Please feel free to fire any issues you
| may encounter.
| llimllib wrote:
| I wrote a similar tool I'm no longer maintaining:
| https://github.com/llimllib/gpt-bash-cli/ . Here are my
| suggestions:
|
| - save the conversations in a sqlite db. ~everyone has sqlite
| available and it allows the user to do things with the data more
| easily than a text file
|
| - use XDG directories instead of suggesting ~/.ellrcd
| (https://wiki.archlinux.org/title/XDG_Base_Directory)
|
| - I prefer using system secret stores to environment variables; I
| don't want to give every program I run access to my API keys. You
| can see how I did that in my program
| simonmysun wrote:
| Thanks for the suggestions! I read your code and the support of
| images is awesome.
|
| I would not assume everyone has sqlite but this can be done
| optionally with a plugin. Will consider writing a demo for
| this.
|
| Using XDG directories and system secrets sounds a lot better
| than what I did. I will learn how to use them and try to
| integrate them with my code!
| ComputerGuru wrote:
| Shameless plug: we maintain a cross-platform/cross-language
| secrets store (with cli tooling available) to portably read
| and wrire secrets (but it doesn't use the OS facilities for
| encryption).
|
| Linking to the rust implementation because it's the fastest
| and most easily portable:
| https://github.com/neosmart/securestore-rs
| ducktective wrote:
| >I prefer using system secret stores to environment variables
|
| What is the recommended way to store secrets in a Linux dev
| machine? The requirement is random scripts and programs should
| be able to load their secrets like API keys at runtime with
| minimum hassle. And the secrets shouldn't be stored on disk in
| plain-text.
|
| I see you recommended keyring [1]. Is this "the GNU/linux way"?
| I see another possibility being storing them in an encrypted
| filesystem (whether FUSE-based or not)
|
| [1]: https://github.com/llimllib/gpt-bash-
| cli/blob/841682affe2d0e...
| llimllib wrote:
| I did a fair amount of looking to try and support a Linux
| secret store! My conclusion was that I was too confused and
| so I punted to keyring which seemed to paper over a few
| different stores.
|
| It seems like a classic story of unfortunate Linux
| fragmentation
| amelius wrote:
| I don't have sqlite, and I wouldn't know how to use it.
|
| I would much prefer text files.
|
| Thank you.
| fragmede wrote:
| you can visit the website https://www.sqlite.org/ where you
| can find copies of the program, along with instructions on
| how to use it. I would prefer to use a more advanced file
| format to hold records. Standing on the shoulders of giants,
| instead of their toes, as it were. Hopefully we can advance
| technology beyond the 1980's. Thank you for your
| understanding.
| trescenzi wrote:
| Huge fan of Charmbracelet's mods. I've been using it for months
| now and it works great. Very customizable and the output is
| clean.
|
| https://github.com/charmbracelet/mods
| simonmysun wrote:
| Thank you for letting me know!
|
| It does well with conversation but on the contrary, ell itself
| is stateless (on the aspect of user input and generate
| contents). Conversational use of ell depends on `script` to
| record the terminal output. Though, I can support managing
| historical dialogs via a plugin with side effects. I need to
| consider whether this suits the idea and philosophy of ell.
|
| Well, either I'm not good at googling ro google is not good at
| searching.. I did searched similar projects and never find
| these powerful tools in practice posted by HN users
| yanis_t wrote:
| Very cool!
|
| I wrote a similar tool (in Node.js, though), but was trying to
| make it extensible with plugins.
|
| https://github.com/hiquest/nicechat
| simonmysun wrote:
| (Reading your comment and code reminds me that I might have
| confused user with the terms of the plugin I proposed and the
| plugin in popular LLM backends. I will make it clear in ell
| documents)
|
| What kind of plugins are you going to integrate? I implemented
| the hook system but actually don't have many ideas to add.
| Currently I only added paginator and syntax highlight plugins
| and both of them are applied after getting response from LLM
| backends.
| mFixman wrote:
| The program seems to assume you'll clone it in your home
| directory, and has paths hardcoded to `~/.ellrc.d/`.
|
| This is just bad.
| simonmysun wrote:
| I wouldn't say these paths are hardcoded. They are just default
| values. You can set the variables manually.
|
| What is hard coded is that it indeed looks for configurations
| from `$HOME/.ellrc` and `$PWD/.ellrc`, with lowest precedence.
| Environment variables and command line arguments will overwrite
| them.
| SoftTalker wrote:
| Convention over configuration isn't bad per se, as the
| alternatives tend to devolve to bikeshedding.
| piyushtechsavy wrote:
| Sounds cool.
| simonmysun wrote:
| Thx!
| danenania wrote:
| This is cool! Using pure bash and unix tools is an interesting
| approach. I built Plandex[1] which has some similar goals (no
| dependencies, terminal-based, supports piping into context) but
| it takes quite a different route to get there--I'm using Go and
| compiling static binaries. It's also 'higher level' and
| specifically focused on coding, whereas ell seems like a very
| lightweight and general purpose LLM tool. It reminds me a lot of
| Simon Willinson's `llm` tool[2]. Are you familiar with it?
|
| The recording feature also reminds me of savvy[3].
|
| 1 - https://github.com/plandex-ai/plandex
|
| 2 - https://github.com/simonw/llm
|
| 3 - https://github.com/getsavvyinc/savvy-cli
| simonmysun wrote:
| Thanks! Plandex is also nice! I never thought of such workflow.
|
| Unfortunately, I did not know Simon Willinson's `llm` tool. I
| would imagine he must have written such softwares. It has
| support for more in-depth manipulating of LLMs. ell lacks these
| functionalities and only make use of the most commonly-used and
| also most basic interfaces but has more user experience
| improvements like pagination or syntax highlighting while
| keeping as lightweight as possible. I should mention
| `simonw/llm` in README and channel the user with demand of more
| LLM manipulations there.
| threecheese wrote:
| That's quite an honest and emotionally mature response, and I
| am always glad to find Real People(tm) around the internet.
| Rare these days. Your product looks great btw! Consider me
| another Stargazer, and keep building it.
| skruzel wrote:
| I also have a similar tool called https://autocomplete.sh
| https://github.com/closedloop-technologies/autocomplete-sh
|
| I really just wanted the feeling of tab-based auto-complete to
| just work in the terminal.
|
| It turns out that getting the LLM responses to 'play nice' with
| the expected format for bash_completion was a bit of a challenge,
| but once that worked, I could wrap all the LLMS (OpenAI, grok,
| Claude, local ones like Ollama)
|
| I also put some additional info in the context window to make it
| smarter: a password-sanitized recent history, which environmental
| variables are set, and data from `--help` of relevant commands.
|
| I've just started to promote it around the Boston area and people
| seem to enjoy it.
| stared wrote:
| Looks interesting!
|
| Does it work with the Fish shell? And, in case, how do I update
| or uninstall it?
| skruzel wrote:
| `autocomplete remove` will delete it. I haven't tested it in
| fish / zsh shells.
|
| Now that I have some Mac iOS dev work to do I'll probably
| build and test it
| simonmysun wrote:
| Wow that's very useful! I have also thought of completion but
| my idea was more like copilot. The user experience of your
| script should be better. I'm glad I didn't start to write that.
|
| Regarding history in context, I suggest adding a record mode
| like ell. This really helps.
|
| Password sanitizer is great. I will also add it as a plugin.
| Thank you for the idea!
| skruzel wrote:
| Thanks for checking it out and the record mode is a great
| idea. I've been playing around with ways to get the terminal
| outputs but so far I haven't loved the UX of my solutions.
| Your co-pilot approach that can explain the commands and
| iterate is really valuable.
|
| If you're open to joining, I have a small AI engineer/ open
| source dev Slack community in Boston. Id love to have you
| (https://smaht.ai)
| simonmysun wrote:
| I am open to join any community. As long as you don't mind
| the fact that I'm not in Bosten, why not? I have just
| submitted on your google form. Thanks for inviting!
| rancar2 wrote:
| The demo video is epic. Nicely done!
| https://youtu.be/IAgkjerCvz8
| skruzel wrote:
| Thank you! It was so much fun to make. And for once my son
| waking me up at 2am had a positive result!
| alkh wrote:
| Looks great! I work on a number of different machines, so having
| something lightweight(like written in shell) is always desired.
|
| Out of curiosity, can someone explain to me why certain commands
| start with a colon? Like : "${ELL_LOG_LEVEL:=2}";[1] I thought it
| was useful only as a no-op? [1]:
| https://github.com/simonmysun/ell/blob/main/ell.sh#L19C1-L19...
| simonmysun wrote:
| Thanks!
|
| The colon is here to make sure the result is not executed. I
| learned that from here:
| https://stackoverflow.com/a/28085062/2485717
| pseufaux wrote:
| The : basically just tells bash to do nothing with the result
| of the line. So `: "${ELL_LOG_LEVEL:=2}";` would initialize
| `ELL_LOG_LEVEL` to 2 if it's not already set without producing
| any output.
| teamspirit wrote:
| Will check it out. Personally been using aichat[0] for this.
|
| It's interesting you say there's no need for a more complex
| language than bash something like this. Doesn't the need for
| jq/curl/perl argue the opposite?
|
| [0] https://github.com/sigoden/aichat
| simonmysun wrote:
| Indeed. That's why I list them as limitations. My original idea
| was to get everything done with Bash. This is however not
| feasible as the reasons listed. Maybe I can get rid of jq and
| perl using awk, but that would sacrifice a lot of simplicity
| and readablity of the code.
|
| I think implementing the syntax highlighter is the bottom line
| of my insist. I would prefer not to write anything more complex
| than that with Bash. They will be either not supported, or
| supported via external plugins.
| joshi4 wrote:
| Ell is really cool!
|
| I'm building a similar product called
| Savvy(https://github.com/getsavvyinc/savvy-cli) and considered an
| approach similar to yours (writing in pure bash) but ultimately
| decided to use Go for a few reasons:
|
| - charmbracelet makes it super easy to build rich TUI - Go
| produces a single binary that's compatible across many platforms
| and keeps installation simple - It's simpler to support multiple
| shells.
| simonmysun wrote:
| Thanks!
|
| Another user[1] also mentioned Savvy but I misunderstood its
| purpose. Now I understand it does have a similar functionality
| of analyzing a record of terminal! Your approach allows more
| chances to let LLM explain what happens, while in my case,
| asking ell will immediately destroy the original context (the
| user may have to rerun the falsy command again and cause more
| damage). However, exiting and reentering recording mode also
| feels tedious. I must find a better way to interact.
|
| https://news.ycombinator.com/item?id=41139040
| threecheese wrote:
| Just checked out Savvy; is the runbook-generating code ('savvy
| record') also in that repository? The one hosted at
| api.getsavvy.
|
| Very interesting idea! Your terminal screenshots are excellent
| as well, very compelling imagery. Love the font.
| raajg wrote:
| Been using the LLM cli by simonw and love it.
|
| https://github.com/simonw/llm
|
| https://llm.datasette.io/en/stable/
|
| Pro tip: Use $pbpaste to inject clipboard contents in a prompt
| simonmysun wrote:
| I don't have pbcopy and pbpaste on my machine but injecting
| clipboard sounds interesting.
| simonw wrote:
| Does ell have the ability to pipe things INTO the tool?
|
| I use that with my https://llm.datasette.io/ tool all the time -
| things like this: cat somecode.py | llm -m
| claude-3.5-sonnet "Explain this code"
|
| Or you can separate the instructions from the piped content by
| putting them in a system prompt instead like this:
| cat somecode.py | llm -m claude-3.5-sonnet --system "Explain this
| code"
|
| Being able to pipe content like this INTO an LLM is really fun,
| it lets you do things like scrape a web page and use it to answer
| questions: https://simonwillison.net/2024/Jun/17/cli-language-
| models/#f...
| simonmysun wrote:
| Definitely! For example, cat somecode.py | ell
| -f -
|
| If you prefer adding another piece of prompt instantly instead
| of adding it in the template: (cat somecode.py;
| echo "Explain this code") | ell -f -
|
| I should've added this into README.
|
| I really love your "llm" and the blog posts but somehow I
| missed them before. I believe I would be a lot less motivated
| to write ell if I had read your post first.
| heyrikin wrote:
| This is really cool.
| simonmysun wrote:
| Thx!
___________________________________________________________________
(page generated 2024-08-02 23:00 UTC)