Si vous parlez d'une application tierce spécifique, utilisez une variable d'environnement. La plupart des programmes transmettront l’environnement entier inchangé lorsqu’ils forkent + exécutent de nouveaux processus.
Alors, démarrez cette application avec une var env personnalisée que vous pouvez vérifier . par exemple, créez un alias pour celui-ci alias vs=RUNNING_FROM_VSCODE=1 VSCode
, ou créez un script wrapper comme ceci:
#!/bin/sh
export RUNNING_FROM_VSCODE=1
exec VSCode "$@"
Ensuite, dans votre .bashrc
, vous pouvez faire
if (($RUNNING_FROM_VSCODE)); then
echo "started from inside VSCode"
# RUNNING_FROM_VSCODE=0 # optional if you only want the immediate child
fi
Une instruction arithmétique bash (( ))
est vraie si l'expression est évaluée à un entier non nul (c'est pourquoi j'ai utilisé 1
ci-dessus). La chaîne vide (pour une variable env non définie) est fausse. C'est bien pour les variables booléennes bash, mais vous pouvez tout aussi bien l'utiliser true
et le vérifier avec un POSIX traditionnel
if [ "x$RUNNING_FROM_VSCODE" = "xtrue" ]; then
echo "started from inside VSCode"
fi
Si votre application efface principalement l'environnement pour ses enfants , mais passe toujours $PATH
inchangée, vous pouvez utiliser ceci dans votre wrapper:
#!/bin/sh
export PATH="$PATH:/dev/null/RUNNING_FROM_VSCODE"
exec VSCode "$@"
et vérifiez-le avec un pattern-match comme bash [[ "${PATH%RUNNING_FROM_VSCODE}" != "$PATH" ]]
pour vérifier si la suppression d'un suffixe de PATH le modifie.
Cela devrait sans danger faire une recherche de répertoire supplémentaire lorsque le programme recherche des commandes externes introuvables. /dev/null
n'est certainement pas un répertoire sur aucun système, il est donc sûr de l'utiliser comme un faux répertoire qui se traduira rapidement ENOTDIR
si les recherches PATH ne trouvent pas ce qu'elles recherchent dans les entrées PATH antérieures.
env
commande. Voyez s'il y a une variable spécifique à VS que nous pouvons utiliser.