3 formas de editar su ruta en la línea de comandos
La variable de entorno PATH es una de las partes más importantes del uso de la línea de comandos en Linux. En un sistema moderno, a menudo es una cadena muy larga de directorios todos separados con dos puntos. Si quieres cambiar un elemento de tu ruta, puede ser molesto tener que teclear y editar un montón de nombres de directorios diferentes y hacerlo todo bien. Por suerte, hay algunas formas de hacerlo más fácil. Lo mismo ocurre con cualquier variable de entorno y la mayoría de las herramientas que te mostraré funcionarán para cualquiera de ellas.
Resumen
Como la mayoría de las cosas en Linux, hay muchas formas de conseguir tu objetivo. Aunque dije que había tres formas de hacerlo, probablemente hay un número infinito de formas, y aquí hay una que no contaré como parte de las tres: Usar la expansión.
Sin embargo, esto sólo funciona si quieres añadir algo al principio o al final de una variable. Por ejemplo, digamos que quieres añadir ~/foo a PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Eso es fácil, pero no ayuda si quieres borrar o cambiar algo en la variable. Tampoco ayuda si quieres cambiar el orden de algunos directorios existentes.
Método 1: La forma más difícil
Asumiendo que estás dentro de una terminal GUI, probablemente tienes una forma de cortar y pegar texto. Así que puede parecer fácil escribir:
echo $PATH
Entonces puede recoger el texto y, en una nueva línea de comandos, introducir PATH=" y pegar el resto del texto. Haz tus cambios, cierra la cita y pulsa Enter. Podrías pensar que eso no es una gran mejora si necesitas editar el texto existente, pero resulta que si presionas CONTROL+X, CONTROL+E en bash, obtendrás una bonita ventana de editor donde puedes editar tu comando. Esto funcionará con cualquier comando, y es muy útil cuando estás sacando una larga línea de comando del historial que necesitas arreglar.
¿Cómo sabe bash qué editor usar? La variable de entorno EDITOR. Si no te gusta el editor que trae por defecto, cambia tu archivo de inicio (por ejemplo, .bashrc) para establecer la variable:
EDITOR=nano
Esto está bien, pero podemos hacerlo mejor. Después de todo, este método requiere que muestres la variable, hagas algo de escritura manual y luego hagas un copiar y pegar.
Método 2: envedit/pathedit
En GitHub, encontrarás scripts para envedit y pathedit. Estos son simples scripts que puedes poner en tu sistema en algún lugar donde puedan ser encontrados (por ejemplo, /usr/local/bin). Si quieres que se encuentren en la ruta, debes hacerlos ejecutables (chmod 755).
El problema es que cualquier cambio que un script haga en el entorno no se mantiene después de que ese script salga (ver la sección ¿Qué es el entorno?, más abajo). Como resultado, usted tiene que originar estos archivos para que funcionen. El script pathedit editará el PATH en su editor favorito mientras que el envedit requiere un nombre de variable y hará el mismo trabajo:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Es un poco molesto tener que recordar que hay que hacer un source todo el tiempo, por lo que los scripts tienen una característica especial. Si los fuentes una vez en su .bashrc y pasar el argumento alias, las secuencias de comandos se establecerá un alias a sí mismos de modo que sólo escribir pathedit o envedit hará que la fuente a suceder:
. pathedit alias # now just typing pathedit will work
Como de costumbre, la secuencia de comandos utiliza $EDITOR para saber qué editor a utilizar. Si quieres un editor especial sólo para este propósito, establece $PATHEDIT_EDITOR o $ENVEDIT_EDITOR y anulará la configuración habitual. Si esto no se establece, el script busca $EDITOR y $VISUAL antes de predeterminar a vi.
Método 3: envedit2/pathedit2
El tercer método también está en la misma página de GitHub. El funcionamiento es justo el mismo que el método 2. Es decir, sigues poniendo los archivos en algún sitio y los llamas con el argumento alias para configurarlos. Sin embargo, estos scripts no utilizan tu editor de texto. En su lugar, cargan el buffer de la línea de comandos de bash con la cadena correcta a editar. Esto es muy similar al primer método, excepto que los pasos son automatizados para usted.
Note que cuando usted ejecuta cualquiera de estos, ellos establecen un alias para envedit o pathedit, así que usted no usará los 2 para usarlos excepto cuando los configure. Eso también significa que el último que configures «gana». No puede configurar ambos al mismo tiempo a menos que haga alguna cirugía de scripts o configure sus propios alias.
Cuando ejecute cualquiera de estos scripts, puede ver que aparece un extraño carácter de escape antes de su prompt. Ese es el informe de estado que desencadena el llenado del buffer. Es inofensivo y si te molesta, sólo tienes que pulsar CONTROL+L para redibujar la pantalla.
Aquí tienes los tres
Si sólo quieres usar estos scripts, ya has terminado. Espero que los encuentres útiles. Si no te interesa cómo y por qué funciona todo esto, puedes parar aquí. Pero si quieres saber más sobre el porqué de estos scripts y cómo funciona el entorno, sigue leyendo.
¿Qué es el entorno?
Puedes pensar en el entorno como una pequeña base de datos que se pasa a cada programa. Por ejemplo, probablemente tengas una variable de entorno llamada EDITOR que suele estar configurada con algo como vi, emacs o nano. Cuando un programa necesita llamar a un editor de texto, averiguará qué editor le gusta usar leyendo esa variable de entorno.
Cuando un programa A inicia otro programa (B), el programa hijo obtiene una copia del entorno, aunque el programa A podría hacer cambios en él antes de lanzar B. Sin embargo, cualquier cambio que haga B sólo está vigente para B y cualquier programa que inicie.
Prácticamente, esto significa que nada de lo que haga en un programa lanzado afectará a cualquier otro programa que no se haya iniciado desde el programa. Esto es un verdadero problema en los scripts de la shell. Por ejemplo, suponga que quiere escribir un script que añada ~/foo al final de PATH. Esto no funcionará:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
El problema es que el script se ejecutará en su propia copia de bash. Cambiará debidamente la variable PATH y luego saldrá, haciendo que la nueva copia de PATH desaparezca. Por supuesto, el cambio estaría vigente para cualquier otra parte del script. Para que esto funcione, necesitarías source el script (y entonces no necesita la línea #!, aunque no está de más dejarla). Supongamos que el nombre del script anterior es foopath. Podrías decir:
source ./foopath
# or the same thing:
. ./foopath
Así es como funcionan algunos de los scripts mencionados, al abastecerse en el shell pueden cambiar el entorno actual del mismo.
Eso es todo, realmente… excepto
Si has llegado hasta aquí, enhorabuena. Espero que encuentres estas herramientas útiles y asegúrate de reportar errores en GitHub.
Ronda de bonificación
Dije antes, que cortar y pegar manualmente podría ser la forma más difícil. Sin embargo, hay otra forma de hacerlo. Si tienes /etc/inputrc o ~/.inputrc configurado correctamente puedes escribir (pero no presiones Enter):
PATH=$PATH
Luego presiona Alt+Control+E y el shell expandirá la variable $PATH por ti. Sin embargo, si intentas:
PATH="$PATH"
Verás que al expandirla se pierden las comillas. Tienes que hacer lo incómodo:
PATH=\"$PATH\"
Luego presiona Alt+Control+E. La salida de bind -P te puede decir si la función shell-expand-line está ligada a algo.