WolfHere’s your regular #CommandLine #PSA: #Starship helps you every time you hit return, in every shell. #Atuin makes history 10x more useful. #Direnv is becoming my friend but I need to understand better how to use it, and it needs additions to work in more situations.(e.g., #uv layout, #pixi layout, better path handling in #GitBashForWindows)
I’ve made progress with #Direnv in #GitBashForWindows. It’s automatically setting environment variables and activating virtual environments in #uv projects. Not yet working with #Pixi. Not yet getting my `$PYTHONPATH` right in these uv projects.
#Direnv is such a disappointment to me. I want it to work in #GitBashForWindows. I want it to automatically activate my chosen #Pixi virtual environment (and set up PYTHONPATH). I’ve put over two hours into it and it still isn’t functioning. I assume this all works fine everywhere that is **not** Windows. But it seems like a great idea!
#Atuin update: I've come to rely on it. It's a must have for my daily shell usage. Works great everywhere ... except on #GitBashForWindows. Lots of problems there. Here's how I solved them:
* Install `ble.sh`. Use `curl` to do this. Do not get it with Git. Do not attempt to build from source.
* Install by sourcing `ble.sh` at the **end** of your `.bashrc`. That's how the instructions about getting it with `curl` tell you to do it. The Git based instructions want you to say something different in your `.bashrc`. You want the `curl` instructions.
* In my install, #Ble was too slow out-of-the-box. Missed keystrokes, etc. I copied the `blerc.template` from the GitHub repo to a local `~/.blerc`, and edited it to disable almost every kind of completion and also syntax highlighting. Speed is now acceptable. (Might be that my #Windows box is too slow. That seems unlikely.)
* I use `vi` mode; #Vim. `ble.sh` picks that up from my `.inputrc`; #Readline. I use #Starship for my prompt. I had to disable in `.blerc` the showing of my current `vi` state (insert, visual, command, etc) and also edit `.inputrc` to not add characters to the prompt to show insert vs command mode. Those changes let me have my normal `starship` prompt.
I do have one problem remaining. It's not related to `atuin`; it's related to the command line itself. In #Bash and #Zsh, it's easy for me to be on the command line and get what I've typed so far directly into my editor; #HelixEditor. Usually something like Esc-v or the like. `ble.sh` doesn't seem to have a way to do that, but maybe I just haven't found it yet.
#Atuin is working great for me (especially with a few configuration tweaks) everywhere and in every #Shell except in complex commands (i.e., commands with pipes and or sub-shells) in Git Bash for Windows #GitBashForWindows. My problem here probably has something to do with the Bash preexec hook or whatever it's called; and it might be fixable.
Here are my tweaks:
```toml
store_failed = true
invert = true # I think this value is a change from the default
search_mode_shell_up_key_binding = "prefix"
```
I work in three different platforms: #GitBashForWindows (mostly, because that’s the environment for my job), #macOS, and #Linux. My shell environment is pretty complex, and as #CrossPlatform a I can make it. The most annoying thing I have to handle in my scripts is the difference between paths on a Windows system vs anywhere else, and especially the leaky magic Git Bash for Windows employs to deal with it (that’s the main thing I want to communicate in this post).
I’m a very experienced #Bash user/programmer, but more and more I find myself converting Bash scripts to #Python.
These days my Python scripts are run via a #uv shebang line, which I love. uv creates an environment to run such a script. That environment is not active while I’m _editing_ the script (using #HelixEditor) so, Helix reports all the symbols that it could only have gotten from that venv. I don’t yet know of a non-brute-force way to fix that (that is the second thing I wanted to communicate in this post).