2009-04-18 15 views
12

Deseo poder decir si existe un comando en cualquier sistema POSIX desde un script de shell.Averiguar si existe un comando en el sistema POSIX

En Linux, que puede hacer lo siguiente:

if which <command>; then 
    ...snip... 
fi 

Sin embargo, Solaris y MacOS which no dan un código de error de salida cuando no existe el comando, sino que publican un mensaje de error a la salida estándar.

Además, recientemente he descubierto que el comando which sí no es POSIX (ver http://www.opengroup.org/onlinepubs/009695399/utilities/)

¿Alguna idea?

+2

relacionado: [shell - Compruebe si existe un programa desde un script bash] (http://stackoverflow.com/questions/592620/check-if-a-program-exists-from-a-bash-script) – mrak

+0

Gracias, no estaba tan claro desde abajo, esto me ayudó @mrak 'if command -v dropbox; entonces Dropbox corriendo ... – Louis

Respuesta

18

command -v es un comando especificado POSIX que hace lo que hace.

Se define que devuelve> 0 cuando no se encuentra el comando o se produce un error.

+2

Estoy 100% de acuerdo con el uso de 'command -v', lo uso todo el tiempo, para verificar la disponibilidad de los comandos. Por ejemplo, 'comando -v CMD>/dev/null || echo 'CMD not found'' No estúpido 'si's requerido !! – TechZilla

+2

@TechZilla: ¿por qué las afirmaciones 'if' son estúpidas? – dokaspar

+0

'if' no es estúpido solo porque es un' si', fue estúpido en este caso de uso ya que es extraño. No hubo agrupamiento, y por lo tanto no hay valor semántico adicional, sería simplemente una reevaluación innecesaria. ¿Se puede justificar de todos modos, absolutamente? Un fanático de cualquier práctica puede justificar casi cualquier cosa, y en este caso la consecuencia es insignificante ... pero no significa que sean correctos, o que todas las cosas sean iguales. Generalmente hago la práctica de esta manera, un comando (prueba incluida) con un solo código de error, sin instrucción if. Una vez que obtenga más, entonces 'si' podría ser más que razonable. – TechZilla

0

Puede leer el stdout/stderr de "que" en una variable o una matriz (utilizando barras de retroceso) en lugar de buscar un código de salida.

Si el sistema no tiene un comando "which" o "where", también puede tomar el contenido de la variable $ PATH, luego recorrer todos los directorios y buscar el ejecutable dado. Eso es esencialmente lo que hace (aunque podría usar algo de almacenamiento en caché u optimización de los resultados de $ PATH).

+0

El problema es que incluso en sistemas que * tienen * que, no estoy garantizado, incluso * habrá * algún resultado ... Supongo que podría verificar que no lo haga "parece un camino" ... – singpolyma

+0

Ah, [-x "' which aeiei' "] podría funcionar ... de nuevo, suponiendo que exista ... – singpolyma

2

POSIX hace decir: “If a command is not found, the exit status shall be 127.” Por lo que podría hacer

<command> 
if [ "${?}" = 127 ]; then 
    <handle not found> 
fi 

Al escribir scripts de shell, a menudo es permisible requerir una shell bash (#!/bin/bash), porque sin matrices es casi imposible de manejar argumentos y/o nombres de archivo con espacios correctamente. En ese caso, bash builtin type -p es equivalente a lo que, y debido a que está incorporado, es portátil.

+2

El tipo sin -p es POSIX, pero POSIX no garantiza que interpreta que el comando no existe como un error. – singpolyma

+1

Bash es un extra en muchos sistemas. Tratar de encontrar si las cosas son compatibles con un shell no estándar no es demasiado bueno. – dwc

+2

En Ubuntu, han intentado cambiar de bash a ssh para tantos scripts como sea posible (especialmente durante el inicio) porque es más pequeño y más rápido para iniciar. Y los BSD no incluyen bash en su instalación base. Tampoco la mayoría de los Unix basados ​​en System V. –

Cuestiones relacionadas