picard - Cómo aprender a navegar en el caparazón de Linux

musicbrainz picard español (11)

Quiero dejar de perder un tiempo precioso al tratar con el shell de Linux / Unix.

Si pudiera entenderlo bien, sería genial. De otra manera:

Puedo terminar perdiendo un día solo por configurar un crontab.
Me seguiré preguntando por qué el shebang en este script no funciona.
Me seguiré preguntando cuál es la verdadera diferencia entre:
- . run.sh
- ./run.sh
- . ./run.sh
- sh run.sh
- sh ./run.sh

Verás, es este tipo de cosas las que paralizan mi vida en Linux / Unix.

Como programador, quiero mejorar mucho en esto. Supongo que es mejor quedarse con el shell bash ampliamente utilizado, pero podría estar equivocado. Cualquiera que sea la herramienta que uso, necesito entenderlo hasta sus entrañas.

¿Cuál es la solución definitiva?

Creo que sumergirse en él es la respuesta. Es como aprender a caminar, escribir, usar un teclado ergonómico o escribir en dvorak. Comprométete por completo. Y sí, se ralentizará por completo. Y te verás obligado a mirar tus manos o googlear cosas constantemente. Pero eventualmente llegará a ti.

Curiosa historia, maté el acceso a Internet de mi apartamento haciendo un lanzamiento de ifconfig. Completamente no sabía que ifconfig renew no era un comando. Tuve que llamar a un amigo cuando google no se cargó;) dhcpcd más tarde y volví a googlear todo.

Hay algunas guías en línea decentes que lo ayudarán a sentirse más cómodo en el caparazón. Por ejemplo:

Tutorial de scripts de shell Unix / Linux de Steve Parker
Programación de shell de UNIX , por Stephen G. Kochan y Patrick H. Wood, disponible en línea en Google Books. También disponible en tapa dura. Amazon lo tiene.
Creación de scripts en shell UNIX con sh / ksh . Aparentemente utilizado como parte de una clase en Dartmouth College. ksh es el shell Korn, y está lo suficientemente cerca como para que la información sea útil.

Dedica algo de tiempo a leer ese tipo de tutoriales y, sobre todo, a jugar en el caparazón. Muy pronto, comenzará a sentirse como $ HOME. (Bien, perdón por el mal juego de palabras ...)

La forma en que aprendí realmente en Linux fue instalar gentoo. Lleva una eternidad pero comienzas a ver cómo todo se une.

Ve a buscar las últimas instrucciones y comienza a seguirlas. Hazlo lo suficiente y comienza a pegarse.

Después de un tiempo te sientes cómodo construyendo todo desde cero.

La mejor manera de aprender es leyendo y luego probando cosas. Las páginas de MAN a menudo son muy útiles, y hay muchísimos tutoriales de scripts de Shell. Si lo que busca es crear scripts de shell, simplemente lea y luego practique las cosas que lee escribiendo pequeños scripts que hagan algo ordenado o divertido. Si busca más información sobre todas las diferentes aplicaciones de línea de comandos que se pueden ejecutar desde un shell, estas son más dependientes de la distribución, por lo que debe buscar en la documentación de su distribución favorita.

Las páginas man son probablemente la solución "definitiva". Siempre estoy sorprendido de las gemas que contienen.

Incluso puede usar man bash para responder algunas de las preguntas que plantea en esta pregunta.

Me parece que tratar de aprender un nuevo comando usando las páginas man a veces es abrumador.

Prefiero las páginas man para refrescar mi memoria.

Cuando quiero aprender un comando, busco ejemplos, luego uso las páginas man para ajustar lo que quiero que haga.

Oralmente tiene un libro anterior que te enseña sobre bash y bash scripting al final. La mayoría de todo lo que necesita saber está en la web, pero se extiende.

Pruebe las páginas de BASH del Proyecto de Documentación de Linux aquí [tldp.org] .
PD: La diferencia es eso. es lo mismo que el comando de origen. Esto solo requiere permiso de lectura. Para usar ./run.sh, necesita ejecutar permisos. Cuando usa ''sh'', especifica explícitamente el comando con el que desea ejecutar el script (aquí, solo necesita permiso de lectura). Si está usando un intérprete de comandos para ejecutarlo, no debería haber un problema allí. Si desea utilizar un programa diferente, como ''python'', podría usar python run.py Otro truco es agregar una línea #!<program> al comienzo de su secuencia de comandos. En su caso, #!/bin/sh haría, y para Python, #/usr/bin/env python es lo mejor.

Si bien seguir con Bash podría ser lo mejor, mientras aprendes, la concha de pez podría ser un poco más fácil de usar. Jugué con él durante unas semanas, y aunque no parecía tan poderoso como bash, parecía bastante fácil de usar.

Solo por diversión:

. run.sh . run.sh --- "Fuente" el código en run.sh. Por lo general, esto se usa para obtener variables de entorno en los procesos de shell actuales. Probablemente no desee esto para un script llamado run.sh
./run.sh --- Ejecuta el script run.sh en el directorio actual. En general, el directorio actual no está en la ruta predeterminada (consulte $PATH ), por lo que debe llamar la ubicación relativa de forma explícita. El . el carácter se usa de manera diferente que en el ítem n. ° 1.
. ./run.sh . ./run.sh --- Fuente el script run.sh en el directorio actual. Esto combina el uso de . de los artículos # 1 y # 2.
sh run.sh --- Usa el intérprete sh shell en run.sh Bourne Shell suele ser el predeterminado para ejecutar scripts de shell, por lo que probablemente sea el mismo que en el elemento n.º 2, excepto que encuentra el primer run.sh en $PATH lugar de uno en el directorio actual.
sh ./run.sh --- Y esto es generalmente lo mismo que # 2 excepto Wordier.

Las interfaces de línea de comando, como los diversos intérpretes de intérpretes de comandos, tienden a ser muy esotéricas, ya que deben incluir una gran cantidad de significado en una pequeña cantidad de caracteres. De lo contrario, escribir tarda demasiado.

En términos de aprendizaje, te sugiero usar bash o ksh y no dejes que nadie te convenza de otra cosa hasta que te sientas cómodo. No aprenda con csh o tendrá que desaprender demasiado cuando comience con un shell tipo Bourne más adelante.

Además, las entradas de crontab son un poco más complicadas que otros usos de shell. Supongo que perdiste tiempo porque tu entorno estaba configurado de forma diferente que en la línea de comando. Sugeriría comenzar en otro lugar si es posible.

usa mucho el caparazón, escribe "[nombre-prog] --ayuda" mucho, escribe "man [nombre-prog]" mucho, y toma notas sobre lo que funciona y lo que no funciona, incluso si esas notas parecen obvias en el momento. Para mañana, podrían no ser tan obvios, nuevamente. OTOH, ¡en un par de semanas definitivamente deberían estarlo!

Eche un vistazo a algunos de los muchos libros sobre cómo trabajar con conchas, como From Bash a Z Shell (que cubre Bash y Z), recorra con dificultad un tutorial de shell-scripting o el manual de Gnu Bash.