Nice! I use a combination of an endless bash (zsh) history with timestamps that I navigate via fzf and ctr+r and comments I occasionally add to commands via # at the end followed by my annotation so that I can rediscover the command.
I do this ever since I switched to a Mac in 2015 and my history has over 60,000 lines. So that’s basically my knowledge base :)
Exactly my setup including the #tag's. It is my second brain.
What I love about this is the fzf's fuzzy narrow down. You don't have to start at the beginning of command, you don't have to worry about exact spelling. Just a few snippets you remember, it will narrow it down really fast.
I use the same fuzzy search narrow downs in Emacs.
Shells that use readline (such as bash) may have a history search feature built-in and on by default. Try pressing Ctrl-r or Cmd-r and see if a prompt pops up.
You can build your own workflow by hand by doing something like:
1. Turn on your shell’s feature to record command history.
2. Look into its feature set to control things such as how many entries it remembers, whether it remembers duplicate entries, and whether it timestamps each entry. (Don’t forget to restart each instance of your shell, if needed, for changes to take effect.)
3. Install a tool such as fzf that allows interactive filtering of arbitrary text. (Via Homebrew it’s `brew install fzf`. It’s likely something similar for other package managers.) These tools usually: read lines of input, prompt the user to optionally filter but eventually select a line, then just print that line.
4. Write the necessary shell script(s) / functions / aliases to do things like:
+ invoke the fuzzy-finder on the shell’s history file or a modified version of that file (for example, a modified version that excludes bash’s timestamp lines, or that joins them - perhaps in a human-readable format - with the command it timestamps.)
+ process the output of the fuzzy-finder tool (for example, to copy the command to the clipboard, paste it into the shell, or execute it immediately - which will necessitate things like removing any timestamps or additional notation added in the previous step.)
Step 4 can be easy as something approximating (I’m on mobile right now):
Your gif in your README features a prompt asking to "show all files in this directory" but the 'ls -lh' returned and selected in the demo gif does not show all files, just the ones that aren't hidden. I'd have chosen a more accurate interaction for the demo.
I'm trying to get this to work with ollama. I'm on Arch Linux, fish shell, new to ollama, and only very rarely used pipx. I get:
raise ValueError("OPENAI_BASE_URL and OPENAI_API_KEY must be set. Try running `zev --setup`.")
ValueError: OPENAI_BASE_URL and OPENAI_API_KEY must be set. Try running `zev --setup`
even when I run (for example) set -x ZEV_USE_OLLAMA 1; zev 'show all files and all permissions'
creator here. It pulls env variables from a file in your appstorage directory. I need to change this in a future release to make it cleaner, since I don't think i like it intermingling with env variables.
I’m debating changing it. I do pull in env vars to use as default values (e.g. you already have an API key set). But I might transition way from env variables.
I don't like most of these commands because they just execute. This one is nice because it will be in your history. The current trick I use is to use copilot.vim at the command line. It naturally fits into my flow.
Recently some of my friends reported that it just wants to do comments and I've noticed that it actually biases towards that nowadays, so I start it with something to get it kicked off.
I've been managing to try to figure out what in the prompt makes it like that, but for the moment that little workaround gives me both the comment and the command in my history so it's easier to r-i-search for it.
Instead of being a separate command, I released a set of key bindings you can push that start the LLM prompt with your current command line, and if you successfully accept the suggestion, replace your command line with the result, bypassing the manual clipboard step, and making it so that the result goes into your shell history as a normal command.
Thanks! My main issue is that i'm lazy and although i often know approximately what i want i don't want to type a lot of words to describe it exactly. For example writing `zev 'show disk usage'` is somewhat ambiguous. Am i talking about my current folder or the harddrive? My idea was that rather than typing out what I want explicitly, i want to type the minimum amount and then just select the best of available options.
Since it's generating terminal commands dynamically, what safeguards (if any) are in place to avoid generating destructive or insecure commands (like rm -rf /, etc.)?
1) When you are selecting a command you get a little description at the bottom telling you what it does.
2) this doesn’t run anything. It goes to your clipboard and you have to run it yourself
3) this a good callout… what do u think? I’m thinking maybe ask the models to return a Boolean is_dangerous plus a small explanation and then I can display dangerous commands in red and show the warning when you select one.
Yes, this is a concern. When I built something similar (gencmd.com), I avoided the auto-run option even though it was easy to implement. imho, it's better to have a human in the loop for these.
atuin is a collection of the past, which can be training data for a collection in the future. If I'm asking AI to essentially generate commands, my previous inputs ideally would be part of the basis.
it should run outside of a virtual env and is intended to be installed locally. That said, it currently has too many dependencies (IMO) and i'm working on cutting them down to avoid conflicts.
It uses locally hosted (or remote) LLMs to create and execute shell commands that you describe. You can go as far as writing "shell scripts" in natural language.
Nice! I use a combination of an endless bash (zsh) history with timestamps that I navigate via fzf and ctr+r and comments I occasionally add to commands via # at the end followed by my annotation so that I can rediscover the command.
I do this ever since I switched to a Mac in 2015 and my history has over 60,000 lines. So that’s basically my knowledge base :)
But your project looks nice. Will check out.
Exactly my setup including the #tag's. It is my second brain.
What I love about this is the fzf's fuzzy narrow down. You don't have to start at the beginning of command, you don't have to worry about exact spelling. Just a few snippets you remember, it will narrow it down really fast.
I use the same fuzzy search narrow downs in Emacs.
I miss it everywhere else.
Fish has built in fuzzy search on ctrl-r as well, with no extra config needed
Can you explain how you achieve this?
Shells that use readline (such as bash) may have a history search feature built-in and on by default. Try pressing Ctrl-r or Cmd-r and see if a prompt pops up.
You can build your own workflow by hand by doing something like:
1. Turn on your shell’s feature to record command history.
2. Look into its feature set to control things such as how many entries it remembers, whether it remembers duplicate entries, and whether it timestamps each entry. (Don’t forget to restart each instance of your shell, if needed, for changes to take effect.)
3. Install a tool such as fzf that allows interactive filtering of arbitrary text. (Via Homebrew it’s `brew install fzf`. It’s likely something similar for other package managers.) These tools usually: read lines of input, prompt the user to optionally filter but eventually select a line, then just print that line.
4. Write the necessary shell script(s) / functions / aliases to do things like:
+ invoke the fuzzy-finder on the shell’s history file or a modified version of that file (for example, a modified version that excludes bash’s timestamp lines, or that joins them - perhaps in a human-readable format - with the command it timestamps.)
+ process the output of the fuzzy-finder tool (for example, to copy the command to the clipboard, paste it into the shell, or execute it immediately - which will necessitate things like removing any timestamps or additional notation added in the previous step.)
Step 4 can be easy as something approximating (I’m on mobile right now):
Fzf installs hooks automatically for ctrl+r and a bunch of other stuff
Search for `fzf --bash`. Note that the version in the ubuntu repos is too old to have this feature (I think)
Not op but you need fzf and you need to increase the history size of your bash/ssh whatever
https://github.com/junegunn/fzf
Your gif in your README features a prompt asking to "show all files in this directory" but the 'ls -lh' returned and selected in the demo gif does not show all files, just the ones that aren't hidden. I'd have chosen a more accurate interaction for the demo.
Kind of a good example of how AI gets it "almost" right.
I'm trying to get this to work with ollama. I'm on Arch Linux, fish shell, new to ollama, and only very rarely used pipx. I get:
raise ValueError("OPENAI_BASE_URL and OPENAI_API_KEY must be set. Try running `zev --setup`.") ValueError: OPENAI_BASE_URL and OPENAI_API_KEY must be set. Try running `zev --setup`
even when I run (for example) set -x ZEV_USE_OLLAMA 1; zev 'show all files and all permissions'
creator here. It pulls env variables from a file in your appstorage directory. I need to change this in a future release to make it cleaner, since I don't think i like it intermingling with env variables.
That said, did you run `zev --setup`?
Why are you using env variables when you don't pull them primarily from the process env?
I’m debating changing it. I do pull in env vars to use as default values (e.g. you already have an API key set). But I might transition way from env variables.
btw, feel free to open an issue on github :)
I don't like most of these commands because they just execute. This one is nice because it will be in your history. The current trick I use is to use copilot.vim at the command line. It naturally fits into my flow.
Recently some of my friends reported that it just wants to do comments and I've noticed that it actually biases towards that nowadays, so I start it with something to get it kicked off.
I've been managing to try to figure out what in the prompt makes it like that, but for the moment that little workaround gives me both the comment and the command in my history so it's easier to r-i-search for it.
https://x.com/arjie/status/1575201117595926530
You just set up copilot for neovim normally and set it as your EDITOR. https://wiki.roshangeorge.dev/index.php/AI_Completion_In_The...
You may be interested in copying some of the usage patterns from my similar project: https://github.com/CGamesPlay/llm-cmd-comp
Instead of being a separate command, I released a set of key bindings you can push that start the LLM prompt with your current command line, and if you successfully accept the suggestion, replace your command line with the result, bypassing the manual clipboard step, and making it so that the result goes into your shell history as a normal command.
I really like how it gives you multiple options to choose from. I've been using https://github.com/simonw/llm-cmd
Thanks! My main issue is that i'm lazy and although i often know approximately what i want i don't want to type a lot of words to describe it exactly. For example writing `zev 'show disk usage'` is somewhat ambiguous. Am i talking about my current folder or the harddrive? My idea was that rather than typing out what I want explicitly, i want to type the minimum amount and then just select the best of available options.
Named after Zev from the film Remember? A few years back I wrote a Vim plugin to remember things with the same name :-)
ha, no, just a coincidence. Named after someone i know named Zev. But chose it because it's short and not taken on Pypi
https://docs.aws.amazon.com/codewhisperer/latest/userguide/c...
Looks like cw from aws
Nice! Little plug for what I did too, in a similar vein - it has a web version https://gencmd.com/ and also a cmd line version.
Since it's generating terminal commands dynamically, what safeguards (if any) are in place to avoid generating destructive or insecure commands (like rm -rf /, etc.)?
1) When you are selecting a command you get a little description at the bottom telling you what it does.
2) this doesn’t run anything. It goes to your clipboard and you have to run it yourself
3) this a good callout… what do u think? I’m thinking maybe ask the models to return a Boolean is_dangerous plus a small explanation and then I can display dangerous commands in red and show the warning when you select one.
sounds like a solid plan
Just fyi, this is now implemented
Yes, this is a concern. When I built something similar (gencmd.com), I avoided the auto-run option even though it was easy to implement. imho, it's better to have a human in the loop for these.
Why not https://docs.atuin.sh/?
different use case. atuin is for past commands, whereas this uses an LLM to give you options for commands.
Feels like this should be an extension to atuin instead of a separate tool.
Why? Besides both involving terminal commands, they serve very different purposes.
atuin is a collection of the past, which can be training data for a collection in the future. If I'm asking AI to essentially generate commands, my previous inputs ideally would be part of the basis.
how do I install it with pip? It requires to be in virtual environment. (
Use something like pipx or uv
it should run outside of a virtual env and is intended to be installed locally. That said, it currently has too many dependencies (IMO) and i'm working on cutting them down to avoid conflicts.
Newman!
Somewhat related, here's a little project I've done with LLM: https://github.com/regnull/how.sh
It uses locally hosted (or remote) LLMs to create and execute shell commands that you describe. You can go as far as writing "shell scripts" in natural language.
[dead]
[dead]
Hi Zev!