It’s like pipes and redirection and numbered/named FDs, I think. Once you know about them you just constantly use them without thinking but it’s nearly unconscious - and yet someone else may be awed by learning about them

Job control too!

every so often I find myself wanting the ability to run a pipe chain but with some kind of resumability, in a just-far-enough-to-be-beyond-job-control sense that still isn’t enough to write a whole-ass program

and the amount of times I write the pattern while read line; do ...{nested instructions, multiple shellscripts}...; done < inputfile, same

but I know that doing this on current shells would be a big ball of spaghetti nightmarecode, and be incredibly painful to debug when it any time fails (and it is a when, not an if, because current shells just don’t have that kind of safety)

continuing down that ideological avenue, I find myself considering that powershell, while being an extremely shitty shell, really does have a nice thing going with the rich API surface (and that follows from other things in the environment, but I digress)

that leads me to thinking about things like oilshell etc, which while interesting still don’t really scratch my itches here

at this point about 5~10min has passed since I started writing the pipechain. I breathe deeply, sigh about computers, bang out a shitty one-liner, and wish I had a pile of free money to spend on just building better tools. with a secondary flash of thinking that, despite Developer Experience things being en vogue over in the bay, this just absolutely wouldn’t get money because it isn’t pretty and visible (and then sigh deeply at that too, bottling up the impending flash of rage)

i actually quite like ansible; the alternatives aren’t much better (and i did use all of them, starting from the unlamented cfengine), they just suck differently.

…and people mostly know at least a bit about ansible (i might start moving some parts of the machinery to saltstack, which i hate the least these days, but it’s owned by vmware, and vmware is now being manhandled by broadcom.)

also, i’m not really prejudiced against go tools – as long as they’re maintained by someone else and easily installable in binary form.

regarding gopass; i wouldn’t use it just for myself, just like i wouldn’t use pass – they’re of no use for me personally; gopass manages the integration with git in a very easy way, knows to push changes automatically when secrets are created or updated and is extremely easy to set up as a secret storage for a small group of users: you just need to generate some throwaway gpg keys and you’re all set. and it does have a nice ansible lookup support, which means i can autogenerate secrets on first use, regenerate them automatically when needed, and never bother to know them unless it’s really necessary.

as for desk, it’s a nice way to delineate, say, workspaces, i.e. set up separate shell environments for interactive work. not for everyone, but i already write too much glue code in bash. so when i start work, i just run “desk work”, and it starts the right vpn, autologs me into teleport, and adds the required ssh keys to the agent. (unfortunately it cannot yet trigger the time accounting system, but if our hr annoys me badly enough once more time, i’ll work on that too.)

if it works for you that’s great I guess

I hate my computers being slow. I hate slow shells for the same reason as I hate modern js stacks, chrome being everything that chrome is, and FUCKING ELECTRON: all wasteful garbage trading low developer attention (“VELOCITY”) for user suffering. fuck that completely.

the core of my zsh setup is really rather simple:

function load_if_exists() {
  [[ -a $1 ]] && source $1
}

function path_if_exists() {
  [[ -a $1 ]] && path=($1 $path)
}

function var_if_exists() {
  [[ -a $1 ]] && export $2=$1
}

use like so:

# nixos
load_if_exists ${HOME}/.nix-profile/etc/profile.d/nix.sh

# python local shit
path_if_exists ${HOME}/.local/bin

# virtualenv
load_if_exists /etc/bash_completion.d/virtualenvwrapper

scope OS-/platform-local things by slapping them under a folder: ${HOME}/.zsh/{macos,linux,...}

I keep things like nvm/pyenv/etc out of my normal shell flow until needed (this could be where I’d use rtx, need to try habit it):

% functions enable_pyenv
enable_pyenv () {
	export PYENV_ROOT="${HOME}/.pyenv"
	path=(${PYENV_ROOT}/bin $path)
	eval "$(pyenv init --path)"
	eval "$(pyenv init -)"
	if which pyenv-virtualenv-init > /dev/null
	then
		eval "$(pyenv virtualenv-init -)"
	fi
	pyenv virtualenvwrapper
}

% functions enable_nvm
enable_nvm () {
	export NVM_DIR="${HOME}/.nvm"
	load_if_exists /usr/local/opt/nvm/nvm.sh
	load_if_exists /usr/local/opt/nvm/etc/bash_completion.d/nvm
	load_if_exists /opt/homebrew/opt/nvm/nvm.sh
	load_if_exists /opt/homebrew/opt/nvm/etc/bash_completion.d/nvm
}

other aliases, functions, etc I load in a very simple fashion. this is among my earliest config, and One Day™ I’ll enrich this a bit to be more like the other loaders:

source ${HOME}/.zsh/aliaslist   # list of files with aliases
source ${HOME}/.zsh/functionlist    # list of files with functions, broken up by context
source ${HOME}/.zsh/env_scripts/loader    # loader for other things like lscolour, etc etc

that’s really about all of the complexity. very, very simple. done so to make inter-host use as painless as possible. it’s one of the rules I chose over a decade ago for how I do my computering, and it’s served me incredibly well