Live data from Hacker News

Show HN: Ell – A command-line interface for LLMs written in Bash

github.com

81–88 of 88 posts

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#81
post #57

Earlier quoted context omitted.

> I would not assume everyone has sqlite but this can be done optionally with a plugin. Will consider writing a demo for this. Used to be everyone used BerkleyDB or some similar key-value store - for a great many usecases SQLite is just pragmatically better. And it's arguably less exotic than perl. You should of course do what want - but "just use SQLite" is pretty solid advice when dealing with structured data - and…

I can't deny the benefits. But in my mind, this is not what ell should take care of. It doesn't intend to store anything whether in a text file or any other format. It should however provide the posibilities for users to store them in any way they like.

Fair enough. I seem to recall a project for keeping infinite bash history that did leverage SQLite - interfacing with such a project might be more interesting.

I was more thinking from gp comment that the project might store context or history in its own files - and then SQLite might be a good fit.

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#82
post #81

Earlier quoted context omitted.

I can't deny the benefits. But in my mind, this is not what ell should take care of. It doesn't intend to store anything whether in a text file or any other format. It should however provide the posibilities for users to store them in any way they like.

Fair enough. I seem to recall a project for keeping infinite bash history that did leverage SQLite - interfacing with such a project might be more interesting. I was more thinking from gp comment that the project might store context or history in its own files - and then SQLite might be a good fit.

You may be thinking of McFly —- it’s very good.

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#83
post #46

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…

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.

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#84
post #67

So, last weekend I wanted to use an LLM to review some documents, and the problem I had was not so much the interface but that it's necessary to have some workflow management to re-run failed jobs and run the aggregate job once its dependencies are done. I ended up writing my own to do it, but I wondered if there are off-the-shelf solutions that already provide these kinds of work.

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 promi…

Thank you for your reply, that is good to know that (especially coming from someone with great bash skills). My intent was to have the simplest way to solve my problem and not any more. If I was going to make it more robust I would probably switch to Airflow, Luigi has nice features to make things simple but more limitations. I think there's Flowise that fits the bill for LLM workflow management, but I haven't had the time to investigate yet.

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#85
post #84

Earlier quoted context omitted.

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 promi…

Thank you for your reply, that is good to know that (especially coming from someone with great bash skills). My intent was to have the simplest way to solve my problem and not any more. If I was going to make it more robust I would probably switch to Airflow, Luigi has nice features to make things simple but more limitations. I think there's Flowise that fits the bill for LLM workflow management, but I haven't had th…

Thx! Will look into that.

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#86

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

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

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#87
post #81

Earlier quoted context omitted.

I can't deny the benefits. But in my mind, this is not what ell should take care of. It doesn't intend to store anything whether in a text file or any other format. It should however provide the posibilities for users to store them in any way they like.

Fair enough. I seem to recall a project for keeping infinite bash history that did leverage SQLite - interfacing with such a project might be more interesting. I was more thinking from gp comment that the project might store context or history in its own files - and then SQLite might be a good fit.

Atuin! https://atuin.sh/

Re: Show HN: Ell – A command-line interface for LLMs written in Bash

#88
post #81

Earlier quoted context omitted.

Fair enough. I seem to recall a project for keeping infinite bash history that did leverage SQLite - interfacing with such a project might be more interesting. I was more thinking from gp comment that the project might store context or history in its own files - and then SQLite might be a good fit.

Atuin! https://atuin.sh/

This looks nice! Thanks for mentioning it. I should definitely install this on my servers.
Post reply on HN