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


11

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.


1
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

2
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:


11

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

2
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

6
@mikeserv Nie, $_nie jest standaryzowany przez POSIX. Do 8 parametrów specjalne$@, $*, $#, $$, $!, $?, $-i $0. $_jest wyraźnie pominięty . Niepoprawny komentarz wywołał pytanie .
Gilles „SO- przestań być zły”

19

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


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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.