Dovrei usare una barra alla fine delle variabili del percorso nello script della shell o no? [chiuso]


11

Oggi quando scrivo il mio script di shell.

Improvvisamente mi viene in mente una domanda.

Da allora cd /target_dire cd /target_dir/entrambi funzionano.
Devo aggiungere una barra alla fine delle variabili del mio percorso in uno script di shell?
Come LOG_PATH=/data/nginx/logscontro LOG_PATH=/data/nginx/logs/.

Ho fatto una ricerca volgare su Google, ma non ho trovato discussioni su questo, forse è troppo semplice?

Per ora, è davvero difficile per me decidere quale stile scegliere.
Ma ho preferito lo LOG_PATH=/target_dir/stile un po 'di più.
Perché quando eseguo il completamento automatico con bash, mi viene visualizzato il risultato con una barra.

Qual è la tua opinione al riguardo, perché?



Non c'è una regola. Entrambi gli stili di codifica presentano alcuni vantaggi e alcuni svantaggi.
andcoz,

Risposte:


8

Secondo POSIX:

Definizione di un percorso:

Una stringa utilizzata per identificare un file. Ha caratteri <barra iniziale> opzionali , seguiti da zero o più nomi di file separati da caratteri <barra> . Un nome percorso può contenere facoltativamente uno o più caratteri <barra rovesciata> finali . I caratteri multipli <slash> successivi sono considerati uguali a quelli di uno <slash> , ad eccezione del caso di esattamente due caratteri <slash> iniziali .


@ È interessante sapere che posso cd //e /con il loro nome mostrare in modo diverso sul prompt di bash, e usando visualizzerò pwdun percorso diverso, ma il loro contenuto è identico! Perché?
Zen,


1
Perché bashtiene traccia della directory corrente in modo molto ingenuo, come una stringa. Aggiunge e rimuove euristicamente dal percorso in modo euristico, non si collega al file system reale. Una conseguenza è che puoi inserire un link simbolico e tornare allo stesso modo (se bash non ha deciso che era troppo e lo ha reinizializzato). L'altro è ciò che descrivi. Non dovresti fare affidamento sul tracciamento della directory corrente da parte della shell, non è affidabile.
Orione,


6

Per essere al sicuro, includi la barra. Ciò può comportare più barre durante la concatenazione dei percorsi, ma almeno si evitano problemi.

Alcuni esempi: rsynctratta i percorsi in modo diverso se è inclusa la barra finale (sincronizza quella directory invece di creare un'altra sottodirectory). I collegamenti simbolici alle directory a volte si comportano in modo inaspettato quando non hanno la barra finale - almeno il completamento della shell viene confuso. Non si sa mai se il comando / script che si invoca si basa sul controllo della barra per un comportamento speciale. Potrebbe persino salvarti dalla sovrascrittura di qualcosa. Ad esempio, se si dispone di un file denominato foo, ma si ritiene erroneamente che sia una directory e si desidera spostare qualcosa in esso, quindi mv bar foosovrascriverà il file (perdita di dati, potenziale catastrofe) ma mv bar foo/si lamenterà e non farà nulla.

Quindi, per concludere, nella maggior parte dei casi non importa, ma dovresti usare la barra per proteggerti e anche per rendere più ovvio al lettore umano ciò che intendevi fare in una sceneggiatura. Un osservatore casuale sarà immediatamente sicuro che una variabile si riferisce a una directory se termina con una barra e la utilizzerà correttamente se deve essere modificata.


2

No non dovresti. Aggiunge una barra non necessaria ( /).

esempio

supponiamo che tu voglia esportare la bindirectory di java nella tua PATHvariabile,

export PATH=$PATH:/opt/jre1.7.0_45/bin/

ora controllalo,

user@host:~$ which java
/opt/jre1.7.0_45/bin//java

nota la barra extra ( /) prima di Java, ma fortunatamente funziona solo in questo caso.


Ho visto in questo link c'è una risposta di 31 voti in cui l'autore pensa che dovremmo aggiungere una barra. Non ho capito bene. stackoverflow.com/questions/980255/…
Zen

@Zen, sì, l'ho controllato, era il primo commento della tua domanda. Grazie.
Arnab,

6
Meglio due barre che nessuna. Questo è brutto ma sicuro ... l'altra opzione è molto peggio e può essere pericolosa.
Orione,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.