Czy można używać „.” uruchamiać pliki zamiast źródła - w .bashrc w Ubuntu i OS X?

OK, więc sourceuruchamia skrypt w bieżącej powłoce i .osobno, jak opisano na przykład przy uruchamianiu skryptu za pomocą „.” I „source” , ale konkretnie w moim .bashrcpliku mam:

[ -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

Czy mogę to zastąpić:

[ -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

Czy to zadziała w systemie OS X - czy to problem „POSIX”?

Próbowałem tego i powyższe wydaje się nadal działać na Ubuntu (więc one faktycznie działają z oboma sourcei .to znaczy dają mi pożądaną funkcjonalność w powłoce). Czy powinienem wybierać jeden nad drugim, czy coś mi brakuje?

FWIW, na OS X, czerpię moje .bashrcz mojego .bash_profile.

Jest to definicja POSIX jest od .dot:

Powłoka powinna wykonywać polecenia z pliku w bieżącym środowisku.

Jeśli plik nie zawiera a /<slash>, powłoka używa ścieżki wyszukiwania określonej przez $PATHdo znalezienia katalogu zawierającego plik. Jednak w przeciwieństwie do zwykłego wyszukiwania poleceń plik szukany przez .dot narzędzie nie musi być wykonywalny. Jeśli nie zostanie znaleziony żaden plik do odczytu, powłoka nieinteraktywna przerwie działanie; powłoka interaktywna wypisze komunikat diagnostyczny do błędu standardowego, ale warunek ten nie będzie uważany za błąd składniowy.

Biorąc pod uwagę powyższe, równie dobrze można po prostu wymienić [ -f ./file ] && source ./filesię . ./filecałkowicie. Jeśli pliku nie ma, najgorsze, co się stanie, to dostaniesz powiadomienie przy logowaniu - prawdopodobnie jest to informacja, którą chciałbyś mieć.

Oczywiście, jeśli wolisz zachować test, możesz:

test -f ./file && . $_

W bash, .i sourcesą synonimami. Przeglądając bashkod źródłowy, plik builtin/source.def, możesz zobaczyć .i sourceużyć tej samej funkcji wewnętrznej 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.

Ale sourcenie jest kompatybilny z POSIX, więc jeśli twój skrypt jest wywoływany z POSIX /bin/sh, powinieneś użyć .zamiast source. Ponieważ POSIX nie ogranicza powłoki, wszystkie powyższe skrypty będą działać.

Osobiście zawsze używam .zamiast source. (Wiele skryptów, które napisałem, działa pod cron).