Ejecutar como .test en lugar de ./test

Suponiendo que estoy en la misma carpeta que un archivo ejecutable, necesitaría escribir esto para ejecutarlo:

./file

Preferiría no tener que escribir /, porque /es difícil para mí escribir.

¿Hay una manera más fácil de ejecutar un archivo? Idealmente, solo una sintaxis simple como:

.file

o algo más pero más fácil que tener que insertar el /personaje allí.

Quizás haya alguna forma de poner algo en el /bindirectorio, o crear un alias para el intérprete, de modo que pueda usar:

p file

Puede ser "arriesgado", pero podría haberlo hecho. en tu camino.

Como se ha dicho en otros, esto puede ser peligroso, así que asegúrese siempre. está al final de la RUTA y no al principio.

.se completará automáticamente para./ (escribir .y presionar Tab) al menos en los shells Bash modernos, por lo que no debería tener que usar una PATHsolución compleja o insegura (como la modificación).

Si no se completa automáticamente, es posible que deba instalar el paquete "bash-complete".

o ... quizás dándole al intérprete un alias en el archivo bashrc y luego simplemente

   p  file

Es posible escribir tal función:

p() {
 ./"$@"
}

en su ~/.bashrc. Entonces podrás correr en p app argumentslugar de ./app arguments. Esta solución funciona para ejecutables de cualquier tipo, incluidos scripts y binarios.

"$@"se expande a la lista de argumentos entregados apropiadamente a la función (preservando todos los caracteres especiales de la expansión global o variable) y, como señaló @Scott, bashes lo suficientemente inteligente como para anteponer ./al primero de ellos, preservando el resto.

Podrías ponerlo .en tu $PATHagregando, por ejemplo, PATH=$PATH:.a tu /etc/profile, de esta manera puedes ejecutarlo filesimplemente escribiendo file, a menos que esté en alguna otra carpeta en tu ruta (por ejemplo /usr/bin/). Tenga en cuenta que esto generalmente no es una buena idea.

Por qué es malo: supongamos que se encuentra en una situación en la que no confía plenamente en el contenido de un directorio: lo ha descargado de un lugar poco fiable y desea investigarlo antes de ejecutarlo, o es un administrador de sistemas que ayuda usuario buscando en su directorio de inicio, etc. Desea enumerar el directorio, por lo que intenta escribir ls, pero vaya, comete un error tipográfico y terminó escribiendo sl en su lugar. El autor de este directorio malicioso anticipó esto y colocó un script de shell llamado "sl" que ejecuta 'rm -rf --no-preserve-root /' (o algo más malicioso como instalar un rootkit).

(Gracias @ Muzer por la explicación)

Puedes llamar al intérprete, por ejemplo

bash test

En este caso, el script se ejecutará incluso si no tiene una línea shebang (por ejemplo #!/bin/bash) ni un bit ejecutable. Deberá conocer el intérprete correcto para ejecutarlo también. Puede leer la línea shebang del archivo primero para asegurarse de llamar al intérprete correcto, por ejemplo, si la línea shebang dice

#!/usr/bin/env python3

llamarías

python3 test

Hasta donde yo sé, no hay forma de lograrlo a menos que incluya el archivo en la ruta env, por lo que podría ejecutarlo simplemente escribiendo: file

.fileno funcionará ya que ese es un nombre de archivo diferente. Es un archivo llamado .filey no ./file.

Siento que la barra inclinada puede ser difícil de escribir para ti porque ¿quizás no hay un diseño en inglés? En ese caso, también me sucede a mí, por lo que frecuentemente cambio el diseño de mi teclado al inglés presionando Alt + Shift en Windows (uso Linux desde ssh)

La gente ha sugerido la adición .a PATH, lo cual es peligroso porque crea un riesgo de que accidentalmente ejecutar un programa malicioso plantado en un directorio con permisos de escritura. Pero, si tiene programas ejecutables en algunos directorios de su propiedad y se puede escribir sólo por usted, entonces es seguro (bastante seguro?) Para poner los director (es) en PATH, al añadir una línea como

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

a su ~/.bashrcarchivo Por supuesto, esto significa que puede ejecutar un programa desde uno de esos directorios desde cualquier lugar del sistema de archivos. Por ejemplo, podría cd /etcy escribir foo, y se ejecutaría ~/dev/myprog1/foo. Esto tiene el inconveniente menor de que no puede tener programas con el mismo nombre en más de uno de los directorios. Específicamente, si tiene programas llamados foo en ambos ~/dev/myprog1y ~/dev/myprog2, no podrá ejecutar el segundo excepto especificando una ruta. Del mismo modo, si tiene un ~/dev/myprog1/cat...

Otro enfoque, si solo tiene unos pocos programas con los que hace esto, es definir alias para ellos:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

O puede llamar a los alias .gizmoy .gonzo si lo encuentra más intuitivo.

En realidad, esto tiene, hasta cierto punto, el mismo riesgo de seguridad que poner .en su PATH. Si un usuario malintencionado puede leer su .bashrcy ver sus alias, entonces podría poner malware llamado gizmoy gonzoen directorios aleatorios con la esperanza de que lo ejecute. Es mejor hacer que estos usen nombres de ruta absolutos:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

Por cierto, debe evitar nombrar un ejecutable test, ya que es un comando integrado de shell, y puede ejecutar un programa con ese nombre solo especificando una ruta o algún otro truco.

Para ampliar la respuesta de Zanna sobre intérpretes (lo siento, no hay representante para un comentario): un "intérprete" para ejecutables nativos (también conocidos como archivos binarios ELF) es el cargador dinámico ( ld.so), pero generalmente no entiende la sintaxis que desea:

$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>

(también, a menos que enlace simbólicamente ld.soen su ruta, aún necesitaría escribir /s)

Si se nos permite comenzar a configurar cosas

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

La mayoría de las distribuciones modernas incluyen ~ / .local / bin en $ PATH ya (agregue export PATH="$HOME/.local/bin:$PATH"a su ~/.profilesi la suya no lo hace). Entonces puedes usar x filepara correr ./file.

No intentes definir un .comando. El comando . scriptya se ejecuta scripten el shell actual. Esto permite scriptdefinir variables de entorno para el shell actual.

Si se nos permite hacer scripts de ayuda, puede hacer un ayudante que agregue el pwd a la RUTA, luego ejecute

. pathhelper    #adds pwd to path
file            #now it can be run without ./

Esto evita agregar "." a la ruta y contaminar su .profile con cada ruta en la que en algún momento desee ejecutar algo.

Podemos llevar este enfoque un paso más allá al crear un asistente que inicie un nuevo shell con una RUTA modificada. Si toma un directorio como parámetro (usando pwd como predeterminado), funcionaría como un pushdque edita la ruta. Es posible que tenga que tener en cuenta que cualquier cambio en otras variables de entorno se perdería al salir de la subshell, pero en un shell de larga ejecución, su variable PATH no se saturará. Dependiendo de sus flujos de trabajo, esto podría ser ventajoso.

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

Pero supongo que si quería correr con ella se podía cortar pushdy popdpara que puedan realizar las mismas modificaciones a la ruta sin sin hacer un subnivel que perderá otros cambios.

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(No puede hacer lo mismo cdporque no tiene un análogo popd).

También puede hacer un par de ayudantes dedicados para simplemente empujar y hacer estallar las entradas de RUTA. Lo que funciona mejor realmente depende de sus patrones de uso.

Puede usar la . script.shsintaxis siempre que el script que desee ejecutar esté en el directorio actual.

También puede prefijar con el intérprete, como sh o bash. ejemplo:bash script.sh