Show HN: Ell – A command-line interface for LLMs written in Bash (github.com)

Regarding running ell -r automatically, you can just add it to your .bashrc

> 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

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

It looks beautiful and has many features, why are there so few star?

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

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!

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

I don't have sqlite, and I wouldn't know how to use it.

I would much prefer text files.

Thank you.

On the contrary please don't use the keyring, its annoying and some systems don't have it. Your llm key is not that critical, and you should trust what runs on your system.

Poetry demands access to my keyring and I don't use poetry (open bug for years, it doesnt even need access).

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

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

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.

Convention over configuration isn't bad per se, as the alternatives tend to devolve to bikeshedding.

Thx!

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.

Looks interesting!

Does it work with the Fish shell? And, in case, how do I update or uninstall it?

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!

The demo video is epic. Nicely done! https://youtu.be/IAgkjerCvz8

I've watched autocomplete-sh in action at the AI Tinkerers meetup in Cambridge, MA. Was impressed. It is very well integrated with the shell. The idea of writing it directly in bash - bold! But an effective idea to keep it portable.

Thanks!

The colon is here to make sure the result is not executed. I learned that from here: https://stackoverflow.com/a/28085062/2485717

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.

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.

Second aichat. Super good. For Linux I created a little bash script that downloads the latest binary and unzips it into /home/me/bin

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

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.

I don't have pbcopy and pbpaste on my machine but injecting clipboard sounds interesting.

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.

I have been an LLM skeptic for a long time, but the llm CLI and your review of Claude 3 Opus (and subsequently discovering how comparatively cheap 3.5 Sonnet is) has started to turn LLMs into something I use daily.

Exactly that piping comes into handy all the time. I use it to estimate reading time of things on the web, through

    curl <url> | llm -m claude-3.5-sonnet -s 'How long does the main content of this article take to read? First count words, then convert using a slow and fast common reading speed.'

It gets the word count wrong a little too often for my taste, but it's usually within the right order of magnitude which is good enough for me.

One of my most used shell scripts recently is one I named just `q` which contains

    #!/bin/sh

    llm -s "Answer in as few words as possible. Use a brief style with short replies." -m claude-3.5-sonnet "$*"

This lets me write stupid questions in whatever terminal I'm in and not be judged for it, like

    [kqr@free-t590 tagnostic]$ q How do I run Docker with a different entrypoint to that in the container?

What's nice about it is that it stays in context. It's also possible to ask longer questions with heredocs, like

    [kqr@free-t590 tagnostic]$ q <<'EOF'
    > I have the following Perl code
    > 
    >     @content[sort { $dists[$a] <=> $dists[$b] } 0..$#content];
    > 
    > What does it do?
    > EOF

I have meant to write about this ever since I started a few weeks ago but I would like my thoughts to mature a bit first...

How do you get that claude-3.5-sonnet model to use locally with llm? I wasn't able to figure it out reading the plugin docs.

Thx!

Please stay tuned. Support for more providers are on the way!

I don't have a solution yet but it's also a problem I am trying to address. The output of LLM is not stable and robust and currently we can only adjust the prompt to improve it. Fundamental tools like piping in the shells cannot easily handle this. You must either rerun the whole pipeline or start to write more complex script which includes validating and parsing the output.

I checked your solution and it looks promising. Will you make it a general purpose LLM workflow scheduler?

You are right. I will replace the video. Actually the last time I record it wasn't this bad. And the script was kept and I didn't make much change when recording it again.

Here's the first video I recorded for an earlier version: https://github.com/simonmysun/ell/blob/d4fc5468157fa6adc8f9f...

Unfortunately, LLMs are not stable.

For reference, here's the link to the video with mistake:

https://github.com/user-attachments/assets/1355ad08-6fbf-4c0... https://github.com/simonmysun/ell/blob/553d38f60ad104893b2a3...

That truly is a visionary article; thank you for sharing it. We still cannot afford to be complacent, but I believe it is the responsibility of the users to ensure safe and ethical usage.