IFS null non equivale a IFS non impostato?

Ho letto una grande domanda qui chiamata Understanding IFS . Sono stato sorpreso perché le risposte e i commenti citano POSIX in cui si afferma che IFS = non è lo stesso di IFS non inquietante. Se si disattiva IFS, apparentemente viene utilizzato il valore predefinito. Se si rende Null IFS invece, non c'è splitter. Sapevo di aver visto un approccio diverso su questo, e l'ho trovato nei miei segnalibri:

Bourne Shell Programming

$ IFS

La prima affermazione nella tua sceneggiatura dovrebbe essere

IFS =

che reimposta il separatore del campo di input al suo valore predefinito. Altrimenti, erediti $ IFS dall'utente, che potrebbe averlo impostato su un valore bizzarro per rendere le stringhe di analisi diverse dal modo che ti aspetti e indurre comportamenti strani.

Quindi era vero qualche tempo fa o l'autore ha torto?

Le risposte che hai trovato su Stack Exchange sono giuste e questo tutorial è sbagliato. Puoi sperimentare da solo o cercarlo nello standard . Un unset IFSequivale a impostarlo sul valore predefinito di space-tab-newline, mentre un vuoto IFSdisattiva efficacemente la divisione del campo.

Puoi consultare la pagina di Sven Mascheck su IFS riguardo alle implementazioni storiche. Ad alcune shell storiche non piaceva unset IFS, e una versione molto vecchia di ksh la trattava come una shell vuota IFSma tutte le shell moderne e la maggior parte delle shell vecchie trattano un set non impostato IFScome valore predefinito.

Non dovresti iniziare il tuo script con a IFS=meno che tu non voglia disattivare la divisione dei campi (che può essere una decisione ragionevole - ma nota che devi ancora mettere due virgolette attorno alle sostituzioni per evitare il globbing, a meno che tu non lo disattivi set -fanche con ). Per ripristinare il valore predefinito, utilizzare unset IFS. È discutibile se ciò sia utile all'inizio di una sceneggiatura; ci sono molte altre cose cattive come un inganno PATHche il chiamante può fare per far sì che la tua sceneggiatura vada storta.

Questo tutorial consiglia anche di ripristinare PATH. Questo è di solito un cattivo consiglio. Nella maggior parte dei casi, non è possibile prevedere quale sia il percorso di ricerca corretto, ma l'utente lo sa. Come fai a sapere se /usr/local/bino /home/bob/bincontiene versioni di utilità riparate da errori su un antico unix in cui quelle /usr/binsono buggy? Vuoi davvero incorporare tutta la logica per capire se /usr/xpg6/binanticipare /bin? In quale posizione vuoi /usr/gnu/bin? Non ripristinare PATH a meno che lo script non abbia come target un sistema specifico.

Non ho letto questo tutorial, ma ho verificato una cosa: non ti dice fin dall'inizio di mettere sempre doppie virgolette attorno a sostituzioni variabili e sostituzioni di comandi. Quindi non penso che questo tutorial sia buono.