Me preguntaba si es posible crear un "enlace" en usr/bin (es decir) que conduzca a un script de shell.ejecutando el script de shell sin llamar implícitamente a sh
Pero quiero sólo para escribir
% shellscript
en lugar de
% sh shellscript.sh
un poco como un alias.
¿Esto es posible?
hacer la primera línea del script
#!/bin/sh
Entonces que sea ejecutable escribiendo el comando:
chmod +x shellscript.sh
Si ahora colocar la secuencia de comandos en una carpeta bin que está en su sistema de Variable PATH y podrá ejecutarla directamente. Para ver las carpetas de la ruta, escriba:
echo $PATH
que suelen utilizar para /home/[my username]/bin guiones que he escrito para que no interfieran con otros usuarios en el sistema. Si quiero que sean para todos los usuarios, utilizo /usr/local/bin que se suministra vacío en la mayoría de las distribuciones.
El .sh al final del nombre del archivo de comandos es solo una convención para ayudarlo a recordar qué tipo de archivo es. Todavía funcionará si cambia el nombre a solo shellscript, por ejemplo, que completará sus requisitos.
Gracias por su descripción detallada – ShoX
Puede hacer que el script de shell sea ejecutable (chmod +x shellscript.sh). Luego puede vincular desde/usr/bin (ln -s shellscript.sh /usr/bin/shellscript).
+1 para indicar realmente cómo hacer el enlace 'ln -s script .sh/usr/bin/script' –
Sí. Puede usar ln para crear un enlace al shellscript.sh llamado shellscript. Luego deberá hacerlo ejecutable, pero después de eso (suponiendo que /usr/bin esté en su ruta) puede ejecutarlo con shellscript.
gracias por explicar la vinculación-alternativa! – ShoX
Además de hacer el script ejecutable y su vinculación en/usr/bin, como han sugerido otros, también tendrá que añadir la línea "tinglado" a la parte superior de la secuencia de comandos:
#!/bin/sh
# your commands here
Esto le permite especificar qué intérprete de shell (bash, shell bourne, c-shell, perl, python ...) se debe utilizar para ejecutar su secuencia de comandos.
Consideré esta cuestión de usar extensiones de nombre de archivo en Unix/MacOSX y la mejor respuesta que puedo proporcionar es un pegado de mis comentarios de desarrollo en algún código que escribí hace años para automatizar todo el tedioso proceso de actualización de scripts que escribo para su inclusión en/usr/local/bin.
I have begun to
change how I develop code for my contributions to
/usr/local/bin. In the past I would always leave the development
file without an extension and depend on the shebang
#!/usr/bin/env ...) line. The flaw with using this approach
exclusively is it does not allow me to utilize the code colorizing
capabilities I have available for programming languages as deftly
as I might. Also allot of development environments do not
understand shebang and so see the code as plain text. Nor are the
contents of files without file extensions accessible via the MacOSX
QuickLook feature...
En resumen, mi código de automatización (más bien mucho para publicar aquí) 'sudo' inserta una copia de extensión-menos ejecutable del programa en// local/bin usr pero el archivo en el directorio de desarrollo mantiene su extensión de lenguaje de script/programa en su lugar. Ambas copias tienen la misma línea shebang en la parte superior del archivo.Muchas otras tareas repetitivas también están automatizadas en este código de automatización, por supuesto. Pero la recompensa final es la 'sobrecarga' asociada con el proceso de escribir nuevos 'comandos' o modificar los comandos existentes/usr/local/bin 'que ahora requieren un par de pulsaciones de teclas.
Permanezco en Snow Leopard y sigo siendo cauteloso con Lion. Entonces, si las cosas son diferentes en Lion, me disculpo por cualquier confusión. Además, si su sistema operativo no tiene el equivalente de QuickLook, parte de lo que he dicho puede perderse, pero creo que cualquier usuario de Linux/Unix puede beneficiarse de la coloración de código a través de vim/less (http: // www- zeuthen.desy.de/~friebel/unix/less/README) comandos.
Un ejemplo de parte de mi salida automatizada de código repetitivo colorizing que facilita QuickLooking a través de código en el directorio de desarrollo:
/usr/bin/highlight --syntax sh --style neon -i "/Users/pcs/Projects /Shell/Bash/findpdftext/findpdftext.sh" >| "/Users/pcs/Projects/Shell /Bash/findpdftext/findpdftext.sh.html"
la generación de este html repetitivo me cuesta nada y es más bonito en QuickLook que las páginas man que son generado automáticamente también. Otro pequeño ejemplo de salida automatizada que entra en el script en el directorio de desarrollo del programa que se ejecutará cuando esté listo para enviar cualquier cambio al script en cuestión a la copia 'command' en/usr/local/bin:
##################################### REWIRE findpdftext.sh:
chmod 777 "/Users/pcs/Projects/Shell/Bash/findpdftext/findpdftext.sh"
cp -f "findpdftext.sh" "findpdftext"
sudo ln -f "findpdftext" /usr/local/bin
cp -f "findpdftext" "/Users/pcs/man/cat1/findpdftext.1"
############### SYMBOLIC-LINK-NAMES supplied from command-line:
##### fpdf is a symbolic link to findpdftext
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpdf"
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpdf.1"
############### SYMBOLIC-LINK-NAMES supplied from command-line:
##### fpt is a symbolic link to findpdftext
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpt"
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpt.1"
En conclusión, para mí hay razones para usar ambos estilos de nombre de archivo.
recuerda a la línea shebang como la primera línea del script para que esto funcione –
¿Todos nombran sus scripts de shell .sh? Yo * nunca * uso una extensión '.sh' en los guiones, así que siempre escribí 'shellscript' –
@Stephen P - Tiendo a nombrar los míos .sh (o .bash) si son pequeños que yo ' Solo voy a necesitar algunas veces y ejecutar desde mi carpeta de inicio, pero coloque la extensión si voy a moverlos a una carpeta bin y compartirlos con otros usuarios o usarlos mucho. – rjmunro