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.

osx bashrc posix

— Michael Durrant
źródło

Jeśli chodzi o powłoki oparte na „sh”, używałbym ”. dla globalnej kompatybilności i jeśli używasz powłok opartych na „csh”, użyłbym źródła.

— mdpc

Gdzie w łączonym poście widzisz, że „ sourceuruchamia skrypt w bieżącej powłoce i .osobno”? Obaj uruchamiają go w bieżącej powłoce; inaczej nie byłoby sensu

— Michał Mrożek

Odpowiedzi:

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 && . $_

— mikeserv
źródło

Ludzie wiedzą $_, że to lubię. :)

— Andreas Wiese

@AndreasWiese - każdy powinien - to jeden z zaledwie 7 specjalnych parametrów zdefiniowanych przez POSIX.

— mikeserv

+1 Skończyło się na test -f /.file && . $_pokazanym tutaj podejściu

— Michael Durrant

@mikeserv Nie, $_nie jest standaryzowany przez POSIX. Do 8 parametrów specjalne są $@, $*, $#, $$, $!, $?, $-i $0. $_jest wyraźnie pominięty . Niepoprawny komentarz wywołał pytanie .

— Gilles „SO- przestań być zły”

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).

— Cuonglm
źródło

Wszystkie rzeczy są równe, użyj „source” zamiast „.” z jednego powodu: spróbuj wyszukać / grep dla „.” wyrażenia dużym skryptem. To koszmar.

— abonet

Chociaż ta odpowiedź wyjaśnia, dlaczego używanie .jest zwykle „lepsze” niż używanie source, jak mówi @abonet, sourcejest o wiele łatwiejsze do wyszukiwania. Ponieważ kropki są interpunkcyjne w wielu językach, łatwo jest je pominąć. Dlatego wolę używać source.

— Joe