Percentuale nella variabile d'ambiente $ PATH

Il mio $ PATH è simile al seguente:

/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

In bash, posso senza problemi invocare la bacchetta situata in

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

piace

$ 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

Tuttavia, nella modalità di compatibilità bourne shell, non è possibile trovare la bacchetta:

$ wand
sh: 2: wand: not found

Sembra che il problema sia il segno% in questi percorsi. Questo segno è stato aggiunto con la codifica URL in modo che il nome "GNU / Linux" possa essere utilizzato nel nome della directory anche se non è un nome file valido. È possibile far funzionare il nome in sh o far funzionare il comando sh come bash. Ossia, fai in modo che bash si comporti allo stesso modo anche se è stato invocato con il comando / bin / sh, che comunque collega a bash.

— user877329
fonte

Bella domanda Sembra che il carattere '%' non shfunzioni correttamente in $ PATH da (va bene dentro bashe zshcomunque). Chiamare direttamente l'eseguibile funziona sh; veramente strano.

— Rmano,

Cosa succede se usi il 2 %%?

— Mikeserv,

O sfuggire al%?

— mdpc,

Questa non è la shell Bourne, o bashemulazione della shell Bourne, è la shell Almquist, nel tuo caso probabilmente la shell Debian Almquist (un fork Linux di Debian degli sh BSD stesso basato sulla shell Almquist originale).

Nella shell Almquist (quella originale e le versioni moderne), %viene utilizzata PATHper funzionalità extra specifiche ash. Citando dalla documentazione:

Ricerca percorso

Quando si localizza un comando, la shell cerca prima di vedere se ha una funzione shell con quel nome. Quindi, se PATH non contiene una voce per %builtin, cerca un comando incorporato con quel nome. Infine, cerca ciascuna voce in PATH a sua volta per il comando.

Il valore della variabile PATH dovrebbe essere una serie di voci separate da due punti. Ogni voce è composta da un nome di directory o da un nome di directory seguito da un flag che inizia con un segno di percentuale. La directory corrente deve essere indicata da un nome di directory vuoto. Se non è presente alcun segno di percentuale, la voce induce la shell a cercare il comando nella directory specificata. Se il flag è %builtin quindi viene cercato l'elenco dei comandi incorporati della shell. Se il flag è %func allora la directory viene cercata per un file che viene letto come input per la shell. Questo file dovrebbe definire una funzione il cui nome è il nome del comando da cercare.

I nomi dei comandi che contengono una barra vengono semplicemente eseguiti senza eseguire alcuna delle ricerche di cui sopra.

Ad altre shell piace ksho zshhanno un meccanismo di caricamento automatico simile delle funzioni, ma usano una variabile diversa ( $FPATH), ma non è possibile definire quale delle funzioni o degli eseguibili abbia la precedenza.

Nel tuo caso, /home/torbjorr/deployed/vector/x86_64-GNU%2fLinuxviene interpretato come la /home/torbjorr/deployed/vector/x86_64-GNUdirectory con il 2fLinuxflag. Quella bandiera viene ignorata in quanto sconosciuta.

Non c'è modo di aggirare questo. Anche se la cenere aveva un meccanismo di fuga in modo che questo %non può essere trattata in modo speciale, che sarebbe poi non funziona in altre shell o altre cose che guardano $PATHcome execvp().

Dovrai rimuovere i %caratteri da $PATH, quindi rinomina la tua directory o aggiungi un link simbolico.

O non usare ashper il tuo /bin/sh. Altre implementazioni di shell POSIX leggere che non lo fanno includono yashe mksh.

— Stéphane Chazelas
fonte

Sebbene questa risposta fornisca una spiegazione, non fornisce una soluzione. Esiste un modo compatibile per mantenere%.

— user877329

@ user877329, non esiste una vera soluzione qui. Vedi la mia modifica.

— Stéphane Chazelas,

In altre parole, Debian shviola lo standard POSIX. Dato che il punto di avere un separato shè esattamente che dovresti essere sicuro di non inciampare su un'estensione della shell incompatibile (immagino che nessuno usi /bin/shcome shell di accesso in questi giorni), considererei un bug.

— Celtschk,

@celtschk, concordato anche se il punto di usare ashper / bin / sh è più per evitare la penalità prestazionale dell'uso bash, quindi usare yasho mksh(o poshse si desidera escludere tutte le estensioni) è ancora un'opzione migliore che usare bash. Inoltre, si può considerare un caso angolare. Normalmente nessuno avrebbe %un componente path. La maggior parte delle shell ha casi angolari in cui non sono conformi a POSIX.

— Stéphane Chazelas,

@mtmiller, non è così che ho letto il significato del set di caratteri del nome file portatile (PFCS). POSIX specifica le API di programmazione ma non le implementazioni del filesystem. il PFCS è il minimo che POSIX garantisce che funzionerà qualunque sia il filesystem, qualunque sia la localizzazione corrente ma non è una scusa per uno strumento di non accettare un carattere in un nome file se è supportato dal filesystem e valido nella localizzazione corrente. Si noti che ad esempio POSIX richiede che ci sia un [comando anche se quel carattere non è nel PFCS.

— Stéphane Chazelas,