During snap install, we commonly need to configure a generic config file that has invalid or dummy values built into the snap with runtime files and sometimes we need to use tools available in the core snap (i.e. sed, grep, awk) to do this such as jq, so we stage those tools into the snap. In normal snapcraft.yaml defined apps, the environment variables get setup such that we can just use "jq" in a shell script and it is on the $PATH with $LD_LIBRARY_PATH set appropriately, but we need to use jq from a hook and the environment variables aren't setup at all for hooks. This may be by design but is unfortunate as now we have code like this: ``` # add things from the snap's $PATH to here export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH" # setup LD_LIBRARY_PATH, we need to handle the different architecture paths - # this snippet is copied out of one of the generated snapcraft wrappers case $(arch) in x86_64) MULTI_ARCH_PATH="x86_64-linux-gnu";; arm*) MULTI_ARCH_PATH="arm-linux-gnueabihf";; aarch64) MULTI_ARCH_PATH="aarch64-linux-gnu";; *) echo "architecture $ARCH not supported" exit 1 ;; esac # Note - the env var SNAP_LIBRARY_PATH is set by snapd for hooks, so it can be referenced here export LD_LIBRARY_PATH="$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/$MULTI_ARCH_PATH:$SNAP/usr/lib/$MULTI_ARCH_PATH" ``` It would be great if snapcraft or snapd could somehow facilitate adding generic boilerplate code like this for hooks. One easy way I think would be to have snapd gain support for command-chain for hooks like it does for apps today and then in the snap.yaml it would have a snapcraft generated hook that runs before the actual hook in the snap.