search

ayekat / localdir

Personal configuration files
65 stars 3 forks source link

Get rid of remaining wrappers #23

Open ayekat opened 7 years ago

ayekat commented 7 years ago

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:

roosemberth commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

marcthe12 commented 5 years ago

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.