This isn't news, the real news is that the AI tooling allows YOU (specifically) to have a custom prompt tool built specifically for you, in the same or less effort it would take to set up one of the existing prompt tools.
For example, I liked the idea of this but had no interest in the shell history integration; I use atuin.
So I had codex build me one, including the 250ms wait for git, and if git takes longer than that it backgrounds it, uses the last git status until git can return an updated status. https://github.com/linsomniac/jafoprompt
I don’t want my prompt to also handle shell history, and especially in such an “opinionated” way.
What happens to my actual shell-provided history?
Does too much for me.
edit:
> Both files follow the XDG base directory spec, so neither lives in the install directory. Removing whetuu with rm -rf ~/.whetuu cannot take your history with it. whetuu paths prints both locations.
No, they are not? Atuin is not a shell prompt, you can use it with any prompt. Like Starship, Spaceship, liquidprompt, etc. None of those hijack shell history.
we are not talking about the same thing. I'm talking about ~/.whetuu - the tool doesn't hijack the shell history at all. You can rm -rf the store and your shell history is intact.
The XDG spec tells you exactly where to place your files. It isn’t in $HOME/.your-project ever. You know about XDG enough to mention in your docs, so you should know.
It does hijacks shell history. If I press the up arrow, I expect _my shell_ to handle it how I configured it, not your tool. Because you’re saying your tool is a shell prompt!
A shell prompt is the program that runs before and after every shell command to show me contextual information like the current directory, and the exit code of the last command.
If you want this to be include customizations beyond the prompt, stop calling it a prompt.
The XDG Base Directory spec covers config/data/cache/state, it does not define where executables go. Whetuu history & cache are both compliant as both go to respectively ~/.local/share/whetuu/ ($XDG_DATA_HOME) & ~/.cache/whetuu/ ($XDG_CACHE_HOME).Atuin, cargo and many other tools are doing the same. By the way, Atuin also rebinds the up arrow.
User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.
i prefer ~/bin/ but this is better than creating you own directory that needs to be added to the path.
In order to address several comments I got here, the readme and landing pages have been reworked. I can't change the title here but read as: An opinionated, zero-config status line and history picker for fish, bash and zsh, written in Zig. Also tackled several issues mentioned in different comments (including the install to ~/.local/bin).
Unclear to me: does this also do shell history? I'm using atuin and not interested in changing that. I did just switch over to oh-my-posh a few weeks ago and it's good, but I would be open to trying something else to compare, particularly since I have some directories with monorepos where oh-my-posh goes out to lunch for a couple seconds. Also oh-my-posh sometimes loses its mind and switches back to the default prompt rather than my customized one.
I'm on the fence about my current "2-line prompt, collapsing to a single line" when I press enter. I like that it gives me a lot of room, but there's some information I find I'm wishing was persisted in my shell history (git branch, previous command execution time for long running commands).
I stopped using fancy prompts at some point. My current prompt is a single $ sign. If I need to know the current dir I just run cwd, I don't need it on every prompt. If I need the git branch just use git status (though aliased to gs [no, I don't use ghostscript]).
Does that mean you can't go up and fix a typo? If so, that sounds strictly worse than what you get by default from the shell (which is up arrow, ctrl-r and various other methods of history searching, and history substitution or editing to fix errors).
I fixed it - you can go up and edit the last failing one. As soon as another cmd succeeds, it will not longer appear in the list and it's never stored into the tool history.
> Pronounced FEH-too (/ˈfɛ.tuː/). Stress the first syllable. In Māori wh is an f sound, not a w. The macron in ū makes that vowel long, which is why the ASCII spelling doubles it.
You need a Nerd Font. The prompt uses Nerd Font glyphs for the git branch, the language logos and the prompt character. Without one, those show as empty boxes.
this sounds like a nerdfont needs to be installed manually. but that doesn't seem to be the case because it just seems to work. and i don't remember installing such a font.
i also wonder what version it is showing when not in a git repo directory.
finally, how do i edit history entries before rerunning them?
If you see the glyphs correctly, you're very likely having Nerd Font installed. If not in git, it will show https://yamafaktory.github.io/whetuu/#modules. And to edit an entry in the list, hit tab :).
Actually regarding the Nerd Font point, you might be using a terminal supporting it out the box. I'll adjust the readme and the landing page accordingly.
It used to be the case that seeing cool Show HN projects would get me excited. Ever since the advent of agentic coding, that has been completely lost for me. 9/10 times now they are just claude produced slop with a 3 day long commit history. Quite sad.
"curl | sh" certainly feels wrong, but in the end, even if you download and read the script before running commands, let's be real: you are going to run a binary that you didn't inspect.
Not saying you shouldn't check your scripts, I usually do, I like to know where the files are going in case the installer messes up, but the risks tend to be overstated compared to running the executable itself.
that's a fair point, but the script doesn't do much, and this method should not be normalized. i downloaded the release manually, unpacked it, and moved the binary into ~/bin/
what's left is adding the init command to the shell init script.
and it turns out that this is included as an alternate way to install in the repo README.
i really don't see the point of the install script. the verification it offers is of no value because if the repo is compromised then the install script could be compromised too.
What if this project offered binaries from GitHub releases instead? How do you read those?
It's more realistic to decide if you trust the source, GitHub user yamafaktory in this case. Then you can ensure that your method of download uses TLS.
It already does. The releases page has prebuilt binaries for four targets plus a SHA256SUMS file. You can download the tarball straight from GitHub over TLS, verify it against the checksums, and run it. No script involved.
This isn't news, the real news is that the AI tooling allows YOU (specifically) to have a custom prompt tool built specifically for you, in the same or less effort it would take to set up one of the existing prompt tools.
For example, I liked the idea of this but had no interest in the shell history integration; I use atuin.
So I had codex build me one, including the 250ms wait for git, and if git takes longer than that it backgrounds it, uses the last git status until git can return an updated status. https://github.com/linsomniac/jafoprompt
Indeed, this is very opinionated (it's mentioned in the repo / landing page but that was too long for the ShowHN title).
I don’t want my prompt to also handle shell history, and especially in such an “opinionated” way.
What happens to my actual shell-provided history?
Does too much for me.
edit:
> Both files follow the XDG base directory spec, so neither lives in the install directory. Removing whetuu with rm -rf ~/.whetuu cannot take your history with it. whetuu paths prints both locations.
Please stop creating directories in my $HOME.
I do want shell history with folders.
I tried a few (Atuin? McFly?) but the performance wasn't good with my massive zsh history (going back several years).
Zsh+fzf does a buttery smooth job (no folders though, unfortunately). Other tools start to stutter at scale.
Yeah, I do too. From a shell history tool. Not from a shell prompt.
Why not, plenty of tools - atuin included - are doing that.
No, they are not? Atuin is not a shell prompt, you can use it with any prompt. Like Starship, Spaceship, liquidprompt, etc. None of those hijack shell history.
we are not talking about the same thing. I'm talking about ~/.whetuu - the tool doesn't hijack the shell history at all. You can rm -rf the store and your shell history is intact.
The XDG spec tells you exactly where to place your files. It isn’t in $HOME/.your-project ever. You know about XDG enough to mention in your docs, so you should know.
It does hijacks shell history. If I press the up arrow, I expect _my shell_ to handle it how I configured it, not your tool. Because you’re saying your tool is a shell prompt!
A shell prompt is the program that runs before and after every shell command to show me contextual information like the current directory, and the exit code of the last command.
If you want this to be include customizations beyond the prompt, stop calling it a prompt.
The XDG Base Directory spec covers config/data/cache/state, it does not define where executables go. Whetuu history & cache are both compliant as both go to respectively ~/.local/share/whetuu/ ($XDG_DATA_HOME) & ~/.cache/whetuu/ ($XDG_CACHE_HOME).Atuin, cargo and many other tools are doing the same. By the way, Atuin also rebinds the up arrow.
The XDG Base Directory spec covers config/data/cache/state, it does not define where executables go.
it does:
https://specifications.freedesktop.org/basedir/latest/
User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.
i prefer ~/bin/ but this is better than creating you own directory that needs to be added to the path.
Thanks for the hint.
> it does not define where executables go
It does. Read the spec. It’s in $HOME/.local/bin. It’s just not configurable like the other paths.
We’ve been over this. Atuin is not a shell prompt.
I'll try to make that a constructive argument and assume that the project shouldn't use the word "prompt".
In order to address several comments I got here, the readme and landing pages have been reworked. I can't change the title here but read as: An opinionated, zero-config status line and history picker for fish, bash and zsh, written in Zig. Also tackled several issues mentioned in different comments (including the install to ~/.local/bin).
I didn't quite gel with it, seemed overly, well opinionated for no meaningful performance or otherwise improvement to any other simple prompt.
Unclear to me: does this also do shell history? I'm using atuin and not interested in changing that. I did just switch over to oh-my-posh a few weeks ago and it's good, but I would be open to trying something else to compare, particularly since I have some directories with monorepos where oh-my-posh goes out to lunch for a couple seconds. Also oh-my-posh sometimes loses its mind and switches back to the default prompt rather than my customized one.
I'm on the fence about my current "2-line prompt, collapsing to a single line" when I press enter. I like that it gives me a lot of room, but there's some information I find I'm wishing was persisted in my shell history (git branch, previous command execution time for long running commands).
I stopped using fancy prompts at some point. My current prompt is a single $ sign. If I need to know the current dir I just run cwd, I don't need it on every prompt. If I need the git branch just use git status (though aliased to gs [no, I don't use ghostscript]).
This is awesome -
*A history picker on the up arrow*
*Commands are recorded once they finish, and only when they exited cleanly, so typos never clutter the list.*
Where the history is stored? Is it possible to store in single place like user root dir?*
Does that mean you can't go up and fix a typo? If so, that sounds strictly worse than what you get by default from the shell (which is up arrow, ctrl-r and various other methods of history searching, and history substitution or editing to fix errors).
I fixed it - you can go up and edit the last failing one. As soon as another cmd succeeds, it will not longer appear in the list and it's never stored into the tool history.
Thanks for the feedback! You can run `whetuu paths` and will get that, I'll fix the readme.
> Pronounced FEH-too (/ˈfɛ.tuː/). Stress the first syllable. In Māori wh is an f sound, not a w. The macron in ū makes that vowel long, which is why the ASCII spelling doubles it.
oof. deliberate choice?
You're right. Whetuu is actually correct in ASCII. I did study study some Te reo Māori a while ago. Will fix.
Fixed :)
a few questions:
i am confused by this line:
You need a Nerd Font. The prompt uses Nerd Font glyphs for the git branch, the language logos and the prompt character. Without one, those show as empty boxes.
this sounds like a nerdfont needs to be installed manually. but that doesn't seem to be the case because it just seems to work. and i don't remember installing such a font.
i also wonder what version it is showing when not in a git repo directory.
finally, how do i edit history entries before rerunning them?
If you see the glyphs correctly, you're very likely having Nerd Font installed. If not in git, it will show https://yamafaktory.github.io/whetuu/#modules. And to edit an entry in the list, hit tab :).
Actually regarding the Nerd Font point, you might be using a terminal supporting it out the box. I'll adjust the readme and the landing page accordingly.
this looks like an excellent, non-rust alternative to starship. nice job.
Thanks for the feedback :).
It used to be the case that seeing cool Show HN projects would get me excited. Ever since the advent of agentic coding, that has been completely lost for me. 9/10 times now they are just claude produced slop with a 3 day long commit history. Quite sad.
please stop piping into bash or sh. force people to use the editor, read the install script, and tell them how to run it
"curl | sh" certainly feels wrong, but in the end, even if you download and read the script before running commands, let's be real: you are going to run a binary that you didn't inspect.
Not saying you shouldn't check your scripts, I usually do, I like to know where the files are going in case the installer messes up, but the risks tend to be overstated compared to running the executable itself.
that's a fair point, but the script doesn't do much, and this method should not be normalized. i downloaded the release manually, unpacked it, and moved the binary into ~/bin/
what's left is adding the init command to the shell init script.
and it turns out that this is included as an alternate way to install in the repo README.
i really don't see the point of the install script. the verification it offers is of no value because if the repo is compromised then the install script could be compromised too.
What if this project offered binaries from GitHub releases instead? How do you read those?
It's more realistic to decide if you trust the source, GitHub user yamafaktory in this case. Then you can ensure that your method of download uses TLS.
It already does. The releases page has prebuilt binaries for four targets plus a SHA256SUMS file. You can download the tarball straight from GitHub over TLS, verify it against the checksums, and run it. No script involved.