Porcentaje en la variable de entorno $ PATH

Mi $ PATH se ve así:

/home/torbjorr/deployed/vector/x86_64-GNU%2fLinux:/home/torbjorr/deployed/typewriter/x86_64-GNU%2fLinux:/home/torbjorr/deployed/mustudio/x86_64-GNU%2fLinux:/home/torbjorr/deployed/mathext/x86_64-GNU%2fLinux:/home/torbjorr/deployed/doxymax/x86_64-GNU%2fLinux:/home/torbjorr/deployed/c2tex/x86_64-GNU%2fLinux:/home/torbjorr/deployed/x86_64-GNU%2fLinux/wand:/home/torbjorr/deployed/x86_64-GNU%2fLinux/spellesc:/home/torbjorr/deployed/x86_64-GNU%2fLinux/projinit:/home/torbjorr/deployed/x86_64-GNU%2fLinux/herbs:/home/torbjorr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

En bash, puedo sin problema invocar la varita ubicada en

/home/torbjorr/deployed/x86_64-GNU%2fLinux/wand

me gusta

$ wand
(i) Mål från "main.cpp" har registrerats
(i) Skapar katalog "__wand_targets_dbg"
(i) Kör g++ "main.cpp" -fpic -L"/home/torbjorr/deployed"  -g -Wall -std=c++11 -I"/home/torbjorr/deployed" -o "__wand_targets_dbg/cb-template

Sin embargo, en el modo de compatibilidad de bourne shell, no se puede encontrar la varita:

$ wand
sh: 2: wand: not found

Parece que el problema es el signo% en estas rutas. Este signo se ha agregado mediante codificación de URL para que el nombre "GNU / Linux" se pueda usar en el nombre del directorio aunque no sea un nombre de archivo válido. ¿Es posible hacer que el nombre funcione en sh, o hacer que el comando sh funcione como bash? Es decir, hacer que bash se comporte igual a pesar de que se invocó con el comando / bin / sh, que de todos modos se vincula a bash.

— user877329
fuente

Buena pregunta. Parece que el carácter '%' no funciona correctamente en $ PATH desde sh(está bien en bashy zshaunque). Llamar directamente al ejecutable funciona en sh; muy extraño.

— Rmano

¿Qué pasa si usas 2 %%?

— mikeserv

O escapar del%?

— mdpc

Ese no es el shell Bourne, o bashemular el shell Bourne, es el shell Almquist, en su caso, probablemente, el shell Debian Almquist (una bifurcación Linux de Debian de la propia BSD basada en el shell Almquist original).

En el shell Almquist (el original y las versiones modernas), %se utiliza PATHpara funciones adicionales específicas para ash. Citando de la documentación:

Búsqueda de ruta

Al localizar un comando, el shell primero busca para ver si tiene una función de shell con ese nombre. Luego, si PATH no contiene una entrada para %builtin, busca un comando incorporado con ese nombre. Finalmente, busca en cada entrada en RUTA el comando.

El valor de la variable PATH debe ser una serie de entradas separadas por dos puntos. Cada entrada consta de un nombre de directorio o un nombre de directorio seguido de un indicador que comienza con un signo de porcentaje. El directorio actual debe indicarse con un nombre de directorio vacío. Si no hay ningún signo de porcentaje, la entrada hace que el shell busque el comando en el directorio especificado. Si el indicador es, %builtin entonces se busca en la lista de comandos integrados de shell. Si el indicador es, %func entonces se busca en el directorio un archivo que se lea como entrada al shell. Este archivo debe definir una función cuyo nombre es el nombre del comando que se está buscando.

Los nombres de comando que contienen una barra oblicua simplemente se ejecutan sin realizar ninguna de las búsquedas anteriores.

A otros shells les gusta ksho zshtienen un mecanismo similar de carga automática de funciones, pero usan una variable diferente ( $FPATH), pero no puedes definir qué funciones o ejecutables tienen prioridad.

En su caso, /home/torbjorr/deployed/vector/x86_64-GNU%2fLinuxse interpreta como el /home/torbjorr/deployed/vector/x86_64-GNUdirectorio con la 2fLinuxbandera. Esa bandera se ignora ya que se desconoce.

No hay forma de evitar eso. Incluso si la ceniza tenía un mecanismo de escape para que esta %no se trata de forma especial, que sería entonces no funciona en otros proyectiles u otras cosas que mirar hacia arriba $PATHcomo execvp().

Tendrá que eliminar los %caracteres $PATH, así que cambie el nombre de su directorio o agregue un enlace simbólico.

O no lo uses ashpara tu /bin/sh. Otras implementaciones ligeras de shell POSIX que no hacen eso incluyen yashy mksh.

— Stéphane Chazelas
fuente

Aunque esta respuesta da una explicación, no da una solución. ¿Hay alguna forma compatible de mantener el%?

— user877329

@ user877329, no hay una solución real aquí. Mira mi edición.

— Stéphane Chazelas

En otras palabras, Debian shviola el estándar POSIX. Dado que el punto de tener un separado shes exactamente que debes asegurarte de no tropezar con alguna extensión de shell incompatible (supongo que nadie usa /bin/shcomo shell de inicio de sesión en estos días), lo consideraría un error.

— celtschk

@celtschk, de acuerdo, aunque el punto de usar ashfor / bin / sh es más para evitar la penalización de rendimiento del uso bash, por lo que usar yasho mksh(o poshsi desea excluir todas las extensiones) sigue siendo una mejor opción que usar bash. Además, uno puede considerarlo un caso de esquina. Nadie normalmente tendría %un componente de ruta. La mayoría de los depósitos tienen esquinas en las que no cumplen con POSIX.

— Stéphane Chazelas

@mtmiller, no es así como leo el significado del juego de caracteres portátil de nombre de archivo (PFCS). POSIX especifica las API de programación pero no las implementaciones del sistema de archivos. el PFCS es el mínimo que POSIX garantiza que funcionará sea cual sea el sistema de archivos, sea cual sea el entorno local actual, pero no es excusa para que una herramienta no acepte un carácter en un nombre de archivo si es compatible con el sistema de archivos y es válido en el entorno local actual. Tenga en cuenta que, por ejemplo, POSIX requiere que haya un [comando aunque ese carácter no esté en el PFCS.

— Stéphane Chazelas