right, so as the title suggests…

i like linux based OSes because you can pretty much mould your operating system to the shape of your brain. i call it cognitive ergonomy. and i’d like it to catch on. even on a relatively play-it-safe distro like the one i’m currently using, the repos are full of handy little applications to make life immeasurably easier for you, if they aren’t installed already. thanks to xdotool, xdo, wmctrl, and sxhkd, pretty much any action can easily be bound to a shortcut key. for eg, i have xdotool search --name vimnote windowactivate || kitty --title=vimnote nvim -c "norm 13j" ~/notes/index.md bound to mod+n. it’s so simple, and i was so proud of myself when i got it to work (i’m not really a scripty person). i just wanted to make something easy. then i wanted to make it a bit easier. then i was feeling like “idk this is still way too many key presses” so i found a way of making it even easier.

i’ve got a bunch of little hacks like this. before i found qmmp, i set up global keys for mpv so i could listen to podcasts on another workspace. i have ranger set up to give specific info from mediainfo as a preview for audio and video files. (which windows does easily in gui file browser but THAT’S NOT THE POINT OK)

anyway, the ubuntu forums and arch wiki are full of tricks that a lot of people want to set up, i’m curious as to the ones you had to set up for yourself.

  • ffheinEnglish
    6•2 years ago

    At my old job I wanted to use zsh, but all the build and test scripts only worked in bash or csh, because they would depend on you sourcing other scripts setting up the correct environment for the project you were currently working in. The scripts were also quite slow, and sometimes one script would depend on changes to the environment done by a different script, so it wasn’t feasible to simply launch a new bash shell each time I wanted to run something.

    So my hack was to write a zsh function that would spawn a bash process in the background, source the environment depending on your current folder, and then wait for commands. The zsh function then piped the command line to run to bash, which in turn piped any output from the command back to the foreground shell. On the next invocation it would reuse the already running bash process, and if it detected that you had changed dir to a different project it printed a warning that you probably wanted to re-start the bash shell (which was done with another zsh function).

    E.g. b tb7 build would run “tb7 build” in the bash background process while to the user appearing as if had been run normally in a foreground shell. Then b tb7 test would run “tb7 test” in the same bash process as the previous command.

    Since I worked a lot in terminals connected to remote servers, I also wrote zsh functions for copying the current directory, and another for cd-ing to whatever is in the copy-paste buffer. If it was only locally I would press ctrl-shift-t to open a new terminal at the same location, but it doesn’t work if you first have to open another ssh connection. Later I started using tmux and these functions became less useful.

    The third “hack” I made was to easier resume work in terminals where the ssh connection had timed out. My zsh prompt prints a shortened version of the current directory, e.g. “/storage/cnffhein/proj/monkeys/somemodule/dir/anothersubmodule/cloned/src” prints as “/s/c/p/m/s/d/a/c/src >>>” so my function did a depth first search of the file system to find a path that matched the abbreviation and cd:d there. Since everybody had the same prefix to their username and had the same projects checked out I made it search any dir matching my username first. E.g. ccd /s/c/p/m/s/d/a/c/src would find and cd to /storage/cnffhein/proj/monkeys/somemodule/dir/anothersubmodule/cloned/src