Perché non esportare le variabili sulla stessa riga che le assegni?

Da Qual è l'ultimo argomento del comando precedente?

shellcheck ti dice di non esportare variabili sulla stessa riga che le assegni.

Mi chiedevo perché?

Ha lo stesso consiglio si applica a alias, declare, export, local, readonly, e typeset?

bash

— Tim
fonte

Vedi anche Perché non è necessario raddoppiare la virgoletta `$ bar` nell'assegnazione` foo = $ bar`?

— Stéphane Chazelas,

E sono necessarie le virgolette per l'assegnazione delle variabili locali?

— Stéphane Chazelas,

La regola di shellcheck in questione è SC2155. C'è abbastanza buona documentazione nel wiki shellcheck .

— phunehehe,

Inoltre alcune shell meno recenti non accetterebbero exporte assegnerebbero insieme. Il Heirloom Bourne Shell , per esempio, emette un "foo = 2 non è un identificatore" errore.

— Dennis Williamson,

Il problema è che in Bash ogni comando ha un solo codice di uscita. Quando export foo="$(false)"il codice di uscita di falseviene semplicemente scartato. Se invece lo fai

foo="$(false)"
export foo

il primo comando in errore può essere seguito, ad esempio errexitdall'impostazione.

Dichiarare e assegnare una stringa letterale come export foo='bar'ovviamente non soffre di questo problema. Ma il cambiamento è l'unica costante nello sviluppo del software ed è semplicemente una buona pulizia per rendere tali dichiarazioni a prova di futuro suddividendole.

Oltre ai comandi specifici di assegnazione che menzioni ci sono anche più comandi in un singolo compito come foo="$(false)$(true)". Vedere pipefailin man bashper ancora un altro tale trappola.

Un'altra cosa da ricordare è che la sequenza di dichiarazioni e incarichi è talvolta rilevante. Ad esempio, ti consigliamo di dichiarare le variabili prima di assegnarle. (Purtroppo non è possibile dichiarare le variabili prima di assegnarle per la prima volta.)local readonly

— l0b0
fonte

Quindi se uno sta impostando una variabile da un valore letterale e non c'è alcun codice di uscita da scartare, non c'è niente di sbagliato nel fare tutto su una riga.

— Monty Harder,

Per quanto riguarda questo errore di shellcheck, no. Ma dato che le risposte ora cancellate si sono messe a metà tra di loro, la shell Bourne non supportava la sintassi dell'assegnazione export, quindi per alcuni anni si ricevette saggezza riguardo a ciò se il proprio interprete era probabilmente la shell Bourne.

— JdeBP,

@JdeBP, nota che la shell Bourne ha supportato foo=$(cmd) export foo, anche se con lo stesso avvertimento lo cmdstato di uscita è perso (ma ha causato la chiusura della shell in caso di errore set -e).

— Stéphane Chazelas,

Questo è stato coperto dalla mia prima frase.

— JdeBP