Dlaczego katalog główny jest oznaczony znakiem /?

Przeprowadziłem pewne badania na ten temat w Google, ale wyniki były mętne. Dlaczego /znak jest używany do oznaczenia katalogu głównego? Czy są za tym jakieś solidne powody?

Ukośnik /jest znakiem ograniczającym, który oddziela katalogi ścieżkami w systemach operacyjnych typu Unix. Wygląda na to, że postać ta została wybrana w latach 70. XX wieku i według niepotwierdzonych źródeł przyczyny mogą być związane z tym, że poprzednik systemu operacyjnego Multics , będącego poprzednikiem systemu Unix , użył >znaku jako separatora ścieżek, ale projektanci systemu Unix już zarezerwowali znaki >i <oznaczać przekierowanie We / Wy w linii poleceń powłoki na długo przed tym, jak miały wielopoziomowy system plików. Kiedy więc nadszedł czas na zaprojektowanie systemu plików, musieli znaleźć inny znak oznaczający rozdzielenie elementu ścieżki.

Należy tutaj zauważyć, że w powszechnie używanym terminalu ADM-3A Lear-Siegler w latach 70. XX wieku, z którego pochodzi między innymi praktyka używania ~znaku do reprezentowania katalogu domowego , /klucz znajduje się obok >klucza:

Jeśli chodzi o to, dlaczego katalog główny jest oznaczony jako pojedynczy /, jest to konwencja, na którą najprawdopodobniej wpływa fakt, że katalog główny jest katalogiem najwyższego poziomu w hierarchii katalogów, a podczas gdy inne katalogi mogą być pod nim, zwykle nie ma „ powód odwoływania się do czegokolwiek poza katalogiem głównym. Podobnie sama pozycja katalogu nie ma nazwy, ponieważ jest granicą widocznego drzewa katalogów.

Pierwszy hierarchiczny system plików, jaki znamy dzisiaj, został zaprojektowany dla Multics . Projekt został opisany w „Ogólnozadaniowym systemie plików do dodatkowego przechowywania” autorstwa RC Daley i PG Neumanna. Istotną cechą tego systemu plików jest to, że katalog jest plikiem, który może być zawarty w katalogu, tak jak każdy inny plik. Struktura pliku tworzy drzewo, w którym wszystkie węzły inne niż liście są katalogami. Katalog główny drzewa jest zawsze katalogiem. Każdy plik ma nazwę (nazwę wpisu ), która jest unikalna w swoim katalogu nadrzędnym. Katalog główny nie ma nazwy, ponieważ nie znajduje się w innym katalogu.

Aby wyznaczyć plik, musisz opisać ścieżkę z katalogu głównego drzewa. Multics przyjął naturalną składnię dla nazw ścieżek, gdzie jeśli Pjest ścieżką do katalogu i Fjest nazwą pliku, to jest składnią pliku wywoływanego w katalogu, którego ścieżka jest .P>FFP

W czasach, gdy nie chcesz obciążać się katalogami, Multics miał pojęcie katalogu roboczego . Naga nazwa pliku bez wskazania katalogu jest interpretowana jako plik w katalogu roboczym.

Łącząc te reguły, fooznajduje się plik w katalogu roboczym; foo>barto plik w katalogu potomnym katalogu fooroboczego i tak dalej. Reguły te opisują ścieżki względne, ale do zbudowania ścieżek bezwzględnych zaczynających się od katalogu głównego potrzebna jest dodatkowa reguła. Biorąc pod uwagę, że odczytanie nazwy ścieżki od lewej do prawej odpowiada przeniesieniu z korzenia do liści drzewa, korzeń powinien być oznaczony specjalnym znacznikiem po lewej stronie nazwy ścieżki. Ponieważ nazwy plików nigdy nie są puste (ponieważ byłoby to często mylące), żadna względna nazwa ścieżki nigdy nie zaczyna się od znaku >, co czyni go wygodnym markerem dla bezwzględnych nazw ścieżek. Tak więc >fooplik jest wywoływany foow katalogu głównym, >foo>barto plik wywoływany barw katalogu o nazwiefoow katalogu głównym i tak dalej. Pozostawia to katalog główny, który może być pustym ciągiem; jednak często nie jest wygodne używanie pustego łańcucha jako nazwy ścieżki, więc zamiast tego jest zapisywany >, co ma tę dodatkową zaletę, że nazwa ścieżki jest bezwzględna tylko wtedy, gdy jest to jej pierwszy znak >.

Unix przyjął ten projekt od Multics. Ponieważ Unix już używał znaku >do przekierowania wyjścia w swojej powłoce poleceń, jego projektanci wybrali inny znak /do oddzielenia katalogów w nazwach ścieżek.

W komponentach nazw ścieżek w Uniksie nie można używać tylko dwóch znaków: znaku pustego, który kończy łańcuchy w C (język jądra) oraz ukośnika, który jest zarezerwowany jako separator ścieżki. Ponadto komponenty ścieżki nie mogą być pustymi łańcuchami.

Zatem w nazwie ścieżki mamy tylko dwa rodzaje tokenów: ukośnik i komponent.

Załóżmy, że bez dodawania nowych tokenów chcielibyśmy obsługiwać dwa typy ścieżek: względną i bezwzględną. Ponadto chcielibyśmy móc odwoływać się do katalogu głównego, który nie ma nazwy (nie ma rodzica, który nadałby mu nazwę).

Jak możemy reprezentować ścieżki względne, ścieżki bezwzględne i odwoływać się do katalogu głównego, używając tylko ukośnika?

Najbardziej oczywistym sposobem rozszerzenia języka (innym niż wprowadzenie nowego tokena) jest utworzenie nowej składni: nadanie nowego znaczenia kombinacjom tokenów, które są niepoprawną składnią.

Ścieżki zaczynające się od ukośnika nie mają sensu, więc dlaczego nie użyć początkowego ukośnika jako znacznika wskazującego „ta ścieżka jest bezwzględna, a nie względna”.

Ścieżka, która zawiera tylko ukośnik, jest również nieprawidłowa, więc dlaczego nie przypisać jej znaczenia „katalog główny”.

Te dwa znaczenia łączą się ze sobą, ponieważ ścieżka bezwzględna rozpoczyna wyszukiwanie w katalogu głównym. Innymi słowy, wiodący ukośnik można uznać za mający znaczenie:

• przejdź do katalogu głównego i użyj znaku ukośnika.
• jeśli na ścieżce znajduje się więcej materiału, przetworz go jako ścieżkę względną, w przeciwnym razie gotowe.

Następnie moglibyśmy również dodać ukośnik końcowy, co może oznaczać, że „ta ścieżka zapewnia, że ​​ostatni składnik ścieżki jest nazwą katalogu, a nie zwykłego pliku lub innego rodzaju obiektu: ten ukośnik oznacza ten katalog podobnie jak sposób, w jaki wiodący ukośnik oznacza katalog główny. ”

Przy całej powyższej składni nadal mamy składnię o nieprzypisanym znaczeniu: podwójne ukośniki, potrójne ukośniki i tak dalej.

Dlaczego nie po prostu wprowadzić kolejny token i zrobić to inaczej. Jest tak prawdopodobnie dlatego, że projektanci przyjęli ogólnie minimalistyczne podejście. (Dlaczego ededytor wyświetla tylko, ?gdy zrobisz coś źle?) Ukośnik jest łatwy do pisania i nie wymaga zmiany. Język ścieżki z tylko dwoma typami tokenów (komponent i ukośnik) jest łatwy do zapamiętania i używania.

Inną ważną kwestią jest to, że łatwe manipulowanie ścieżkami jest możliwe przy użyciu tylko reprezentacji ciągów. Na przykład możemy dość łatwo „zrootować” absolutne ścieżki do nowego katalogu nadrzędnego:

OLD_PATH=/old/path
NEW_HOME=/new/home

NEW_PATH="$NEW_HOME$OLD_PATH"  /new/home/old/path

To nie zadziałałoby, gdybyśmy wskazali ścieżki bezwzględne w inny sposób, na przykład wiodący znak dolara lub cokolwiek innego:

OLD_PATH=^old/path  # ^ means absolute path
NEW_HOME=^new/home

# now we need more string kung-fu than just catenation
NEW_PATH="$NEW_HOME/${OLD_PATH#^}"

Ten rodzaj kodowania jest nadal potrzebny w niektórych przypadkach, gdy mamy do czynienia ze ścieżkami w stylu uniksowym, ale jest go mniej.