bash-preexec VS nimlock

Or use the excellent bash-preexec plugin that atuin itself relies on to achieve this in a cleaner way: https://github.com/rcaloras/bash-preexec

Use this: https://github.com/rcaloras/bash-preexec/

Funny you say that when the sketchiest part of this submission is the shell script it uses to intercept every command you run: https://github.com/rcaloras/bash-preexec/blob/master/bash-pr...

I don’t know rust, but the rust files in this repo look very straightforward. (Why wouldn’t it? It’s just matching a few hardcoded commands. It’d be easy in any language)

# ~/.bashrc: executed by bash(1) for non-login shells. # see /usr/share/doc/bash/examples/startup-files (in the package bash-doc) # for examples # We use preexec and precmd hook functions for Bash # If you have anything that's using the Debug Trap or PROMPT_COMMAND # change it to use preexec or precmd # See also https://github.com/rcaloras/bash-preexec # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac # don't put duplicate lines or lines starting with space in the history. # See bash(1) for more options HISTCONTROL=ignoreboth # append to the history file, don't overwrite it shopt -s histappend # for setting history length see HISTSIZE and HISTFILESIZE in bash(1) HISTSIZE=1000 HISTFILESIZE=2000 # check the window size after each command and, if necessary, # update the values of LINES and COLUMNS. shopt -s checkwinsize # If set, the pattern "**" used in a pathname expansion context will # match all files and zero or more directories and subdirectories. #shopt -s globstar # make less more friendly for non-text input files, see lesspipe(1) [ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)" # set variable identifying the chroot you work in (used in the prompt below) if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then debian_chroot=$(cat /etc/debian_chroot) fi # set a fancy prompt (non-color, unless we know we "want" color) case "$TERM" in xterm-color|*-256color) color_prompt=yes;; esac # uncomment for a colored prompt, if the terminal has the capability; turned # off by default to not distract the user: the focus in a terminal window # should be on the output of commands, not on the prompt #force_color_prompt=yes if [ -n "$force_color_prompt" ]; then if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then # We have color support; assume it's compliant with Ecma-48 # (ISO/IEC-6429). (Lack of such support is extremely rare, and such # a case would tend to support setf rather than setaf.) color_prompt=yes else color_prompt= fi fi if [ "$color_prompt" = yes ]; then PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ ' else PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ ' fi unset color_prompt force_color_prompt # enable color support of ls and also add handy aliases if [ -x /usr/bin/dircolors ]; then test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)" alias ls='ls --color=auto' #alias dir='dir --color=auto' #alias vdir='vdir --color=auto' alias grep='grep --color=auto' alias fgrep='fgrep --color=auto' alias egrep='egrep --color=auto' fi # colored GCC warnings and errors #export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01' # some more ls aliases alias ll='ls -alF' alias la='ls -A' alias l='ls -CF' # Add an "alert" alias for long running commands. Use like so: # sleep 10; alert alias alert='notify-send --urgency=low -i "$([ $? = 0 ] && echo terminal || echo error)" "$(history|tail -n1|sed -e '\''s/^\s*[0-9]\+\s*//;s/[;&|]\s*alert$//'\'')"' # Alias definitions. # You may want to put all your additions into a separate file like # ~/.bash_aliases, instead of adding them here directly. # See /usr/share/doc/bash-doc/examples in the bash-doc package. if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). if ! shopt -oq posix; then if [ -f /usr/share/bash-completion/bash_completion ]; then . /usr/share/bash-completion/bash_completion elif [ -f /etc/bash_completion ]; then . /etc/bash_completion fi fi # If this is an xterm set more declarative titles # "dir: last_cmd" and "actual_cmd" during execution # If you want to exclude a cmd from being printed see line 156 case "$TERM" in xterm*|rxvt*) PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\$(print_title)\a\]$PS1" __el_LAST_EXECUTED_COMMAND="" print_title () { __el_FIRSTPART="" __el_SECONDPART="" if [ "$PWD" == "$HOME" ]; then __el_FIRSTPART=$(gettext --domain="pantheon-files" "Home") else if [ "$PWD" == "/" ]; then __el_FIRSTPART="/" else __el_FIRSTPART="${PWD##*/}" fi fi if [[ "$__el_LAST_EXECUTED_COMMAND" == "" ]]; then echo "$__el_FIRSTPART" return fi #trim the command to the first segment and strip sudo if [[ "$__el_LAST_EXECUTED_COMMAND" == sudo* ]]; then __el_SECONDPART="${__el_LAST_EXECUTED_COMMAND:5}" __el_SECONDPART="${__el_SECONDPART%% *}" else __el_SECONDPART="${__el_LAST_EXECUTED_COMMAND%% *}" fi printf "%s: %s" "$__el_FIRSTPART" "$__el_SECONDPART" } put_title() { __el_LAST_EXECUTED_COMMAND="${BASH_COMMAND}" printf "\033]0;%s\007" "$1" } # Show the currently running command in the terminal title: # http://www.davidpashley.com/articles/xterm-titles-with-bash.html update_tab_command() { # catch blacklisted commands and nested escapes case "$BASH_COMMAND" in *\033]0*|update_*|echo*|printf*|clear*|cd*) __el_LAST_EXECUTED_COMMAND="" ;; *) put_title "${BASH_COMMAND}" ;; esac } preexec_functions+=(update_tab_command) ;; *) ;; esac

Thankfully, most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Zsh and Fish have built in support for these hooks. Though bash does not have built in support for these hooks, scripts like bash-preexec exist to mimic the behavior of other shells. Using these hooks, we send a custom DCS (Device Control String) from the running session to Warp. This DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.

It's attached to the preexec hook of https://github.com/rcaloras/bash-preexec, so is run before every command. This means that everything goes into one easily-greppable file, but is still separable by PID/host machine - since my work has me walking around a large facility, often I'll remember where I was when I did something but not exactly when, so can narrow down by machine.

This github repo claims to do the same for bash.

> How do you handle maintaining this as you transition through jobs, machines, etc?

Currently, the tool reads ~/.mergerc, which is a JSON file with a list of SSH hosts to SCP history to and from. As long as the history file is in the same place (it tends to be on hosts that I setup, and otherwise I check in default locations) and the host has an entry in ~/.ssh/config, the tool will work. It's really just a wrapper for a few SCP invocations plus a history file (extended) format parser.

Changing servers is just a change in the config file, but it's also helpful for changing jobs, because I can quickly add a bit of filtering before the merging happens. I had to erase some API keys and such a few times, adding `filter` call here: https://github.com/piotrklibert/zsh-merge-hist/blob/master/s... took care of it.

> what is your workflow around maintaining these one off ad hoc "developer boost" type tools?

Good question. I don't have such workflow, at all. When I commit to write something like this, I try to make sure that it has a scope limited enough so that it can be "completed" or "done". In this case, the tool builds on SSH/SCP and a file format that hasn't changed in the last 20 years (at least). So, once I had it working, there was nothing much to do with it after that. The only change I had to do recently was changing `+` to `` in the parser, because somehow (not sure how, actually) an empty command made it into the file. But that's all I had to do in 5 years time.

I'm not as extreme, but suckless.org philosophy appears to work well here. Here's another example: https://github.com/piotrklibert/nimlock - it's a port, done because I wanted to do something in Nim, but it worked for me for years and I suspect it still works now (after going full remote I stopped needing it). There's nothing much that could break (well, Wayland would* break it, but I don't use it), and so there's not much you need to do in terms of maintenance.

As for language choices - these are basically random. I made the zsh-merge-hist in Scala simply because I was interested in Scala back then. I have little tools written in Nim, OCaml, Racket, Elisp, Raku - and even AWK (pretty nice language actually) and shell. That's another reason why making the tools any more complex than what's absolutely necessary would be a problem: the churn in the ecosystems tends to be too high for me to keep track of, especially since I'd need to track 10 of them.

> I'm checking it out

If you have Java installed, `./gradlew installDist` should give you `./build/install/bin/zsh-merge-hist` executable to run. The ~/.mergerc (on the host the tool runs) should look like this:

    {