0

I would like to run specific application in specific folders only. For example for vint application

$ cd /workspace/vim-plugin
$ vint ftplugin/terraform.vim

Should run docker exec -i vim-plugin sh -c "vint ftplugin/terraform.vim" in others folders vint should mean something different or even "command not found".

Solution I'm using now is direnv to add ./.bin folder to the PATH and generate shell scripts in that folder which override or add possibility to run specific app. In example above it would be /workspace/vim-plugin/.bin/vint which in simplify version looks like this:

#!/usr/bin/env bash

docker exec -i vim-plugin sh -c "vint $@"

It's works more or less as supposed to but there are some annoyance with generating this scripts, and parsing script params (single or double quotation params).

My question is, do you have different ideas how to approach this problem in Gnu/Linux environment, shell bash/zsh? Maybe solution from BusyBox when you have one application and just link to it?

Marek Maksimczyk
  • 3

1 Answers1

0

The annoyance with "parsing script params (single or double quotation params)" is because you're not passing $@ in the right way. This is your way:

docker exec -i vim-plugin sh -c "vint $@"

The shell interpreting your script expands double-quoted $@ and the things get messy. See the analysis and what follows in my other answer. The problem is very similar. Your code after an improvement:

docker exec -i vim-plugin sh -c 'exec vint "$@"' -- vint-sh "$@"

I don't know docker at all, but since it can run sh -c … then probably it can run vint … directly. If so, then there is no reason for sh in the first place. The code becomes:

docker exec -i vim-plugin vint "$@"

Hopefully docker exec … does not interpret options after the first argument that looks like a command (here: sh or vint). See the already linked answer where I point out sudo and su behave differently in this subject. Hopefully docker exec is similar to sudo. This documentation makes me believe so.

After docker is started, the shell interpreting the script seems no longer needed. Instead of running the command and waiting, it can replace itself with the command; with exec:

exec docker …

For this you don't need bash, sh should start faster:

#!/usr/bin/env sh
exec docker exec -i vim-plugin vint "$@"

Now your approach with ./.bin in PATH should work. Still adding ./.bin is similarly flawed as adding . to PATH. A better approach is to create a single directory for wrapper scripts, add its absolute path to PATH as the first entry and put a single wrapper for vint there. The wrapper can test its $PWD (with if, elif; or with case) and act accordingly. Program any logic you want. It may turn out you will be able to implement your desired logic in a simpler way in bash than in sh; so you may prefer bash in the shebang after all.

Kamil Maciorowski
  • 81,893