Comment puis-je déterminer la coquille actuelle sur laquelle je travaille ?
Est-ce que la sortie du ps
le commandement seul est suffisant ?
Comment cela peut-il être fait dans différentes versions d'Unix ?
Comment puis-je déterminer la coquille actuelle sur laquelle je travaille ?
Est-ce que la sortie du ps
le commandement seul est suffisant ?
Comment cela peut-il être fait dans différentes versions d'Unix ?
Il existe trois approches pour trouver le nom de l'exécutable du shell actuel :
Veuillez noter que ces trois approches peuvent être trompées si l'exécutable du shell est /bin/sh
mais il s'agit en fait d'un nouveau nom bash
par exemple (ce qui arrive fréquemment).
Ainsi, votre deuxième question, à savoir si ps
La réponse à cette question est " pas toujours ".
echo $0
- imprimera le nom du programme... qui dans le cas du shell est le shell actuel.
ps -ef | grep $$ | grep -v grep
- cela recherchera l'ID du processus actuel dans la liste des processus en cours. Comme le processus actuel est le shell, il sera inclus.
Ce n'est pas fiable à 100%, comme vous pouvez l'avoir autre les processus dont ps
comprend le même numéro que l'ID du processus de l'interpréteur de commandes, surtout si cet ID est un petit nombre (par exemple, si le PID de l'interpréteur de commandes est "5", vous pouvez trouver des processus appelés "java5" ou "perl5" dans la même liste de processus). grep
sortie !). C'est le deuxième problème avec l'approche "ps", en plus de l'impossibilité de se fier au nom du shell.
echo $SHELL
- Le chemin d'accès au shell actuel est stocké dans le champ SHELL
pour n'importe quel shell. La mise en garde est que si vous lancez un shell explicitement en tant que sous-processus (par exemple, ce n'est pas votre shell de connexion), vous obtiendrez la valeur de votre shell de connexion à la place. Si cela est possible, utilisez l'option ps
o $0
approche.
Si, toutefois, l'exécutable ne correspond pas à votre shell actuel (par ex. /bin/sh
est en fait bash ou ksh), vous avez besoin d'une heuristique. Voici quelques variables environnementales spécifiques aux différents shells :
$version
est défini sur tcsh
$BASH
est défini sur bash
$shell
(minuscule) est défini comme le nom réel du shell dans csh ou tcsh.
$ZSH_NAME
est défini sur zsh
ksh a $PS3
y $PS4
alors que le shell Bourne normal ( sh
) n'a que $PS1
y $PS2
set. Cela semble généralement être le plus difficile à distinguer - la uniquement différence dans l'ensemble des variables d'environnement entre sh
y ksh
que nous avons installé sur Solaris boxen est $ERRNO
, $FCEDIT
, $LINENO
, $PPID
, $PS3
, $PS4
, $RANDOM
, $SECONDS
et $TMOUT
.
ps -p $$
como Matthew Slattery fait remarquer. Pour ksh
: echo $KSH_VERSION
o echo ${.sh.version}
.
@Dennish - mon ksh n'a pas encore défini KSH_VERSION. et echo ${.sh.version}
renvoie "Bad Substitution". Voir ma solution ci-dessus
ps -p $$
devrait fonctionner partout où les solutions impliquant ps -ef
y grep
faire (sur toute variante d'Unix qui supporte Options POSIX pour ps
) et ne souffrira pas des faux positifs introduits par la recherche d'une séquence de chiffres qui peut apparaître ailleurs.
Certains shells ont leur propre version intégrée de ps
qui peuvent ne pas comprendre -p
vous devrez donc utiliser /bin/ps -p $$
.
Toutes les coquilles avec lesquelles je suis familier comprennent $$
sauf pour fish
avec lequel vous devriez utiliser ps -p %self
.
En fait, vous ne devriez pas vous fier à des chemins difficiles tels que /bin/ps
. ps
pourrait facilement (en fait, c'est tout à fait normal de nos jours) être installé en /usr/bin
. $(which ps) -p $$
est un meilleur moyen. Bien sûr, cela ne fonctionnera pas pour les poissons, et peut-être pour d'autres coquillages. Je pense que c'est (which ps) -p %self
dans le poisson.
Merci. J'ai trouvé que c'était la meilleure option à utiliser dans un script pour garder les commandes spécifiques à bash. test `ps -p $$ -ocomm=` == "bash" && do_something_that_only_works_in_bash
. (La ligne suivante dans mon script a l'équivalent pour csh).
$SHELL
contient un shell, qui est configuré par défaut pour l'utilisateur actuel. Elle ne reflète pas l'interpréteur de commandes en cours d'exécution. Aussi, il est préférable d'utiliser ps -p $$
que le grepping $$ à cause des faux positifs.
ps est la méthode la plus fiable. Il n'est pas garanti que la variable d'environnement SHELL soit activée et même si elle l'est, elle peut être facilement falsifiée.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
9 votes
Test de capacités particulières (par exemple, est-ce qu'il fait
!
substitution ?) est probablement plus portable que de trouver le nom du shell. Les habitudes locales peuvent vous faire exécuter quelque chose nommé/bin/sh
qui pourrait en fait être ash, dash, bash, etc.2 votes
@msw : Cela semble être un bon commentaire sauf qu'il me laisse me demander "comment ?".
0 votes
Il semble qu'il n'y ait pas de réponse simple à cette question. Si nous ne pouvons pas requête le shell, peut-être que la meilleure approche est de toujours spécifier la coquille. Je ne suis pas sûr que cela soit toujours possible, mais peut-être est-ce plus facile à réaliser que ce que l'on pense généralement.
0 votes
Ceci pourrait vous aider --> opensourceforgeeks.blogspot.in/2013/05/
0 votes
@Aniket, pas autant d'aide que vous pourriez le penser - cela ne s'intéresse qu'à interactive les processus de l'obus.