Confuso sulla configurazione di Linux Path Environment /etc/profile.d/*.sh eseguito due volte?

0

Sto cercando di impostare PKG_CONFIG_PATH su CentOS ecco il codice che ho provato

export |grep PKG_CONFIG_PATH

nessuna uscita, normale ...

echo "$PKG_CONFIG_PATH"
:/usr/local/lib/pkgconfig

perché c'è output qui ??

e se io

sudo sh -c "echo 'export PKG_CONFIG_PATH=$PKG_CONFIG_PATH :/usr/local/lib/pkgconfig' >> /etc/profile.d/path.sh
source /etc/profile.d/path.sh

Ora lo stesso percorso presenterà due volte ........

export |grep PKG_CONFIG_PATH
declare -x PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig:/usr/local/lib/pkgconfig

Quindi se il percorso non è stato ancora impostato da dove proviene quel $ PKG_CONFIG_PATH?

Modifica aggiornamento: la prima parte del problema in realtà non è importante perché dopo il riavvio le variabili vengono cancellate

Per il vero problema penso che sia perché i file all'interno di profile.d sono stati chiamati due volte una volta da / etc / bashrc una volta da / etc / profile. Ci si potrebbe chiedere WTH ?? Perché è successo? BUG ?? TYPO ??

— shadow_wxh
fonte

2

Questa è la differenza tra variabili d'ambiente esportate e non esportate .

Il exportcomando elenca solo le variabili di ambiente esportate , ovvero quelle variabili che sono contrassegnate come ereditabili dai processi figlio, sia perché la shell le ha ereditate dal suo processo padre, sia perché il comando exporto declare -xè stato usato per contrassegnarle come esportabili.

Le variabili non esportate sono utili negli script, poiché è possibile utilizzarle all'interno dello script, ma non ingombreranno l'ambiente di alcun processo figlio.

Per impostare una variabile non esportata, è possibile utilizzare la name=valuesola sintassi:

$ FOO=bar
$ echo $FOO
bar
export | grep FOO
$

Successivamente puoi contrassegnare la variabile come esportabile:

...
$ export FOO
$ export | grep FOO
declare -x FOO="bar"

La shell Bourne classica, infatti, richiedeva l'inizializzazione delle variabili di ambiente in questo modo in due passaggi: prima impostare il valore, quindi contrassegnarlo come esportabile. Quindi potresti ancora vedere questa sintassi negli script della shell che mirano alla massima portabilità:

FOO=bar
export FOO

Le conchiglie moderne consentono di farlo in un solo passaggio:

$ export FOO=bar

Quindi, nel tuo caso, devi aver precedentemente eseguito un PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig, sia manualmente, o all'interno di uno script di provenienza , o come parte degli script di accesso.

— TELCOM
fonte

Lo sospetto anch'io. Ad un certo punto posso impostare la variabile d'ambiente senza esportarla, ma quelle dovrebbero essere un riavvio temporaneo, il sistema rimuoverà quella variabile ma non è il caso e non riesco a trovarlo codice scritto in nessuno dei File. ovviamente posso esportare PKG_CONFIG_PATH =: / usr / local / lib / pkgconfig ma ciò significa che uno qualsiasi dei percorsi preesistenti non è incluso (se esiste per caso) e non è sicuro.

— shadow_wxh

Rettifica Se rimuovo la riga export PKG_CONFIG_PATH = $ PKG_CONFIG_PATH: / usr / local / lib / pkgconfig entrambi echo ed export restituiscono nulla ma se li aggiungo indietro il percorso mostrerà due volte, vedo quel problema.

— shadow_wxh

In effetti sembra che gli script del tuo profilo vengano eseguiti due volte: forse una volta per inizializzare l'ambiente X11 al login della GUI (la shell che esegue lo ~/.Xsessionscript o il gnome-sessioncomando o qualunque ambiente desktop stai usando), e quindi un'altra volta quando apri un finestra shell ?.

— telcoM,

0

In questo momento ho due soluzioni:

Rimuovi questo codice da / etc / bashrc
```
for i in /etc/profile.d/*.sh; do
  if [ -r "$i" ]; then
     if [ "$PS1" ]; then
        . "$i"
     else
       . "$i" >/dev/null
     fi
  fi
done
```
il problema è che non so perché questi codici debbano essere qui, in primo luogo, potrebbero esserci degli effetti collaterali dopo averli rimossi.
Usa semplicemente l'assegnazione diretta in /etc/profile.d/*.sh
```
export PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig
```
ovviamente questo escluderà qualsiasi percorso preesistente, non una pratica standard.

Nessuno dei due sembra essere la soluzione perfetta qualche suggerimento migliore?

Aggiornare :

Fare ① farà apparire questo messaggio di errore dopo che ciascun comando è entrato nel terminale

 bash: __vte_prompt_command: command not found

— shadow_wxh
fonte