Get rid of remaining wrappers

[ayekat]

Using wrapper scripts is a really ugly workaround. On systems that don't have the wrapped programs installed (I mean... claws-mail, darktable, firefox, pidgin on a server?) the commands still show up in the auto-complete.

As this is really just workarounds for upstream fixing their software, this merits another todo-list:

• claws-mail: Sets --alternate-config-dir to XDG_DATA_HOME/claws-mail/ [SOLVED: b7d08db]
• darktable: Sets --configdir to XDG_DATA_HOME/darktable/ [SOLVED: af3a4a2]
• firefox: Have it use an alternative HOME directory (also decribed here: Get rid of remaining dotfile clutter in ~/ #7) [SOLVED: a7bea7f]
• irssi: Has irssi (somewhat) respect the XDG basedir spec + generating the configuration with the password into XDG_RUNTIME_DIR through use of pass.
• mbsync: Has mbsync use XDG_CONFIG_HOME/mbsync/mbsyncrc.
• minecraft: Has Minecraft put its data into XDG_STATE_HOME/minecraft.
• msmtp: Has msmtp use XDG_CONFIG_HOME/msmtp/msmtprc.
• pidgin: Has pidgin use XDG_STATE_HOME/purple/.
• quilt: Has quilt use XDG_CONFIG_HOME/quilt/quiltrc [SOLVED: ccd9c02]
• qutebrowser: Adds dwb-like session handling to qutebrowser.
• sbt: Has ivy2 and sbt use XDG_STATE_HOME/{ivy2,sbt} [Bug report]
• sendmail: Symlink to msmtp wrapper.
• shellcheck: Disables a few warnings [SOLVED: fd4f786].
• sloccount: Dump cache data in XDG_CACHE_HOME and set LANG=C because sloccount otherwise spits out all sorts of errors.
• sudo: Pass -E for launching vim (TODO: this is ugly as hell—find a better way to edit files as root).
• tmux: Has tmux use XDG_CONFIG_HOME/tmux/config.

[roosemberth]

I was exploring a possible solution in zsh preexec, something like this but we'd need to distinguish between different types of wrappers (or better yet, chain processing of different types of wrappers). Ie. Environment variables, additional flags, ...

The implementation of the chains seems quite straight forward, but It'd be zsh-dependent. Personally, I'm okay-ish with this, but if a shell-independent solution comes by, I won't complain. Ideally I'd like something I can source, find the available binaries and wrap them (probably using functions); I wouldn't mind having zsh-magic to update the wrappers on runtime without resourcing the file (or maybe source an optimized version of it).

[ayekat]

but if a shell-independent solution comes by, I won't complain.

And that's the main issue for me ^^
Many of my wrappers are applications that I launch from dmenu, or are launched by another process (e.g. shellcheck by vim), so the solution should certainly work outside of shells.

[roosemberth]

What about having a login hook that creates a "profile" directory containing symlinks to 'activated' wrapper scripts?. Move the wrappers into something like .local/wrappers and add .local/run/bin to $PATH ?

[ayekat]

Not sure if I understood that correctly, but that would only check at login time, and if any of those applications are added at runtime, I'd run into unwrapped commands? Or I would require some process or filesystem hook that is triggered and correctly adds/removes a wrapper whenever that becomes necessary—which I feel would be a little overkill.

I have come to the conclusion that wrapper scripts shouldn't be necessary in the first place, as their purpose is to circumvent shortcomings of upstream, so this should be fixed there instead. A little imperfection with the handling of such (hopefully temporary) workarounds is therefore acceptable for me.

I have now added a checklist to this issue (a bit like in #7) to track this progress.

[roosemberth]

I was thinking something that checks only at llogin time, but checking at runtime with an fs hook wouldn't be a bad idea IMO

I do agree that they shouldn't be necessay, but some upstream modifications will never see the light of day.

As a fixup for the original problem,

On systems that don't have the wrapped programs installed (I mean... claws-mail, darktable, firefox, pidgin on a server?) the commands still show up in the auto-complete

We could use this to have zsh ignore the wrappers directory. It's still ugly to have such dir though :/

[roosemberth]

So, I was tinkering a little bit and I came up with something I feel more confortable with. It's very experimental, but does not clutter $PATH and plays nice with my safeAlias function:

#!/bin/sh
set -x

wrap()
(
  APP="$1"
  read PREPEND
  read INTERPOSE
  read APPEND
  printf "alias %s='%s \\%s %s %s'" "$APP" "$PREPEND" "$APP" "$INTERPOSE" "$APPEND"
)

eval $(wrap darktable <<- dsa
	
	--configdir "$XDG_DATA_HOME/darktable"
	
dsa
)

eval $(wrap tst <<- dsa
	echo
	--
	blabla
dsa
)

set +x

Instead of eval, we could “pipe” this to $XDG_RUNTIME_DIR/etc/profile to be sourced by any interactive shell. Or create executables instead of aliases so that applications can benefit from this via execve ($XDG_RUNTIME_DIR/bin ?).

I'm open to suggestions, but I kinda like the structure bellow, it makes me think of mkScript (writeTextFile)

mkWrapper target <<- end
	$PREPEND
	$INTERPOSE
	$APPEND
end

[roosemberth]

see https://gitlab.com/roosemberth/dotfiles/commit/d0ede0e64cef0f4307066b110f0c8ddbca59c365

[marcthe12]

Nice. Actually rbenv uses a similar method.
There are 4 rbenv commands relevant to this:
rehash
init
exec
which

Rehash regenerates a wrapper over rbenv exec. (basically rbenv exec $@)
Init sets up path and calls rehash
exec using rbenv which exec the correct executables
which find the correct location from environment.

We need in this case which and exec can be a single command.
Init has to be done during environmental setup.
Rehash can be done whenever you need it.
Exec and which can always be embeded in the wrapper like @roosemberth script.
Unfortunately we need wrappers due to some thing can not be upstreamed and a few script require a pre-exec hook so it is actually more tricky. I will try see how to do this will all my requirements.