È corretto usare "." eseguire file anziché sorgente - in .bashrc in Ubuntu e OS X?

OK, quindi sourceesegue lo script nella shell corrente e .separatamente, come dettagliato nell'esecuzione dello script con "." E con "source" per esempio, ma, nello specifico, nel mio .bashrcfile, ho:

[ -f ~/.bash_aliases ] && source ~/.bash_aliases
[ -f ~/.git-completion.bash ] && source ~/.git-completion.bash
[ -s ~/.autojump/etc/profile.d/autojump.sh ] && source ~/.autojump/etc/profile.d/autojump.sh

Posso sostituirlo con:

[ -f ~/.bash_aliases ] && . ~/.bash_aliases
[ -f ~/.git-completion.bash ] && . ~/.git-completion.bash
[ -s ~/.autojump/etc/profile.d/autojump.sh ] && . ~/.autojump/etc/profile.d/autojump.sh

Funzionerà su OS X - è questo il problema "POSIX"?

L'ho provato e quanto sopra sembra ancora funzionare su Ubuntu (quindi funzionano effettivamente con entrambi sourcee ., cioè, mi danno la funzionalità desiderata nella shell). Dovrei scegliere l'uno sull'altro o mi sto perdendo qualcosa?

FWIW, su OS X, ho il mio sorgente .bashrcdal mio .bash_profile.

osx bashrc posix

— Michael Durrant
fonte

Se si tratta di shell basate su "sh", utilizzerei "." per compatibilità globale e se stai usando shell basate su 'csh' userei source.

— mdpc,

Dove nel post collegato vedi che " sourceesegue lo script nella shell corrente e .separatamente"? Entrambi lo eseguono nella shell corrente; altrimenti non avrebbe senso

— Michael Mrozek

Risposte:

Questa è la definizione di POSIX di .dot:

La shell eseguirà i comandi dal file nell'ambiente corrente.

Se il file non contiene a /<slash>, la shell utilizzerà il percorso di ricerca specificato da $PATHper trovare la directory contenente il file. A differenza della normale ricerca dei comandi, tuttavia, il file cercato .dot dall'utilità non deve essere eseguibile. Se non viene trovato alcun file leggibile, si deve interrompere una shell non interattiva; una shell interattiva deve scrivere un messaggio diagnostico sull'errore standard, ma questa condizione non deve essere considerata un errore di sintassi.

Considerando quanto sopra, potresti anche sostituire il tuo [ -f ./file ] && source ./filecon del . ./filetutto. Se il file non è presente, il peggio che accadrà è che riceverai un avviso all'accesso, che probabilmente è un'informazione che vorresti avere, credo.

Ovviamente se preferisci mantenere il test potresti fare:

test -f ./file && . $_

— mikeserv
fonte

Oh, la gente lo sa $_, mi piace. :)

— Andreas Wiese,

@AndreasWiese - tutti dovrebbero - è uno dei soli 7 parametri speciali definiti da POSIX.

— Mikeserv,

+1 Ho finito con l' test -f /.file && . $_approccio mostrato qui

— Michael Durrant,

@mikeserv No, $_non è standardizzato da POSIX. Le 8 parametri speciali sono $@, $*, $#, $$, $!, $?, $-e $0. $_viene esplicitamente omesso . Il tuo commento errato ha suscitato una domanda .

— Gilles 'SO- smetti di essere malvagio'

In bash, .e sourcesono sinonimi. Esaminando bashil codice sorgente, il file builtin/source.def, è possibile visualizzare .e sourceutilizzare la stessa funzione interna source_builtin:

$BUILTIN source
$FUNCTION source_builtin
$SHORT_DOC source filename [arguments]
Execute commands from a file in the current shell.

Read and execute commands from FILENAME in the current shell.  The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.

Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.
$END

$BUILTIN .
$DOCNAME dot
$FUNCTION source_builtin
$SHORT_DOC . filename [arguments]
Execute commands from a file in the current shell.

Ma sourcePOSIX non è compatibile, quindi se lo script viene chiamato con POSIX /bin/sh, è necessario utilizzare .invece di source. Poiché POSIX non limita la shell, tutto lo script sopra funzionerà.

Personalmente, uso sempre .invece di source. (Molti script che ho scritto corrono sotto cron).

— cuonglm
fonte

A parità di condizioni, usa "source" invece di "." per un motivo: prova a cercare / grep per "." espressioni in una grande sceneggiatura. È un incubo.

— abonet

Sebbene questa risposta spieghi perché usare di .solito è "meglio" che usare source, come dice @abonet, sourceè molto più facile da cercare. Poiché i punti sono punteggiatura in molte lingue, è facile per gli occhi saltarli. Ecco perché preferisco usare source.

— Joe,