Dlaczego nie można uruchamiać wbudowanych powłok wielkimi literami, a inne polecenia?

Dlaczego to?

Kiedy to zrobię

CD ~/Desktop

Nie zabiera mnie na pulpit. Ale to:

echo "foo
bar" | GREP bar

daje mi:

bar

— Wyświetlana nazwa
źródło

Sprawdź, alias GREPczy which GREPcoś wyprowadzasz.

— chepner

Proszę bardzo. Masz polecenie o nazwie GREP, które różni się od grep. (To prawda, że może to być tylko łącze twarde lub łącze symboliczne /usr/bin/grep, ale z punktu widzenia powłoki jest to osobne polecenie).

— chepner

Poczekaj: korzystasz z systemu Mac OS X, prawda? HFS + domyślnie zachowuje wielkość liter , co oznacza, że jeśli wielkość liter ma znaczenie podczas tworzenia pliku, ale gdy plik istnieje, w wyszukiwaniu nie jest rozróżniana wielkość liter. Oznacza to, bashże może poprosić o plik o nazwie GREP, ale system plików uważa grepdopasowanie.

— chepner

Tak, ponieważ jest to Unix.

— DisplayName

Systemy plików są niezależne od systemu operacyjnego. Z Mac OS X można korzystać z innych systemów plików i (teoretycznie) można używać HFS + z innymi systemami operacyjnymi. Możesz także ustawić wielkość liter w HFS +; zachowanie z zachowaniem wielkości liter jest tylko domyślne z powodów historycznych.

— chepner

Z pozostałych twoich pytań rozumiem, że używasz OS X. Domyślny system plików HFS + w OS X nie rozróżnia wielkości liter: nie możesz mieć dwóch plików o nazwach „abc” i „ABC” w tym samym katalogu i próbować uzyskać dostęp każda nazwa przejdzie do tego samego pliku. To samo może się zdarzyć w Cygwin lub w systemach plików bez rozróżniania wielkości liter (takich jak FAT32 lub ciopfs ) w dowolnym miejscu.

Ponieważ grepjest to prawdziwy plik wykonywalny, został sprawdzony w systemie plików (w katalogach PATH). Kiedy twoja powłoka szuka /usr/binjednego z nich greplub GREPznajdzie grepplik wykonywalny.

Wbudowane powłoki nie są wyszukiwane w systemie plików: ponieważ są wbudowane, są one dostępne poprzez porównania łańcuchów (z rozróżnianiem wielkości liter) w samej powłoce.

To, co napotykasz, jest ciekawym przypadkiem. Chociaż cdjest wbudowany, dostępny z rozróżnianiem wielkości liter, CDmożna go znaleźć jako plik wykonywalny /usr/bin/cd. Plik cdwykonywalny jest dość bezużyteczny: ponieważ cdwpływa na bieżące środowisko wykonywania powłoki, zawsze jest dostarczany jako zwykła wbudowana powłoka , ale mimo to istnieje cdplik wykonywalny ze względu na POSIX , który zmienia katalog dla siebie, a następnie natychmiast kończy działanie, pozostawiając otaczającą powłokę gdzie to się zaczęło.

Możesz wypróbować te z typewbudowanym :

$ type cd
cd is a shell builtin
$ type CD
CD is /usr/bin/CD

typemówi ci, co zrobi powłoka po uruchomieniu tego polecenia. Po uruchomieniu cduzyskujesz dostęp do wbudowanego, ale CDznajduje plik wykonywalny. W przypadku innych wbudowanych wbudowane i pliki wykonywalne będą w miarę kompatybilne (try echo), ale cdnie jest to możliwe.

— Michael Homer
źródło

dobra odpowiedź. Już miałem powiedzieć cygwin, co miałoby taki sam efekt.

— Joshua

@Joshua Problem OP został rozwiązany, ale myślę, że dla dalszych czytelników pytania odpowiedź oparta na cygwinie byłaby co najmniej tak samo przydatna jak istniejąca; Może możesz uczynić to osobną odpowiedzią, nawet jeśli jest krótka, i odkładając na istniejącą, aby poznać szczegóły?

— Volker Siegel

Dlaczego posix miałby wymagać bezużytecznego polecenia, takiego jak cd, i dlaczego wewnętrzny dysk CD systemu OSX nie kwalifikuje się?

— Jan

51 głosów pozytywnych! Powinienem właśnie opublikować odpowiedź, zamiast komentarza :)

— chepner

/ usr / bin / cd ma cel. składnia to argumenty katalogu / usr / bin / cd

— Joshua