Dlaczego był „.” wybrano reprezentowanie bieżącego katalogu i „..” dla katalogu nadrzędnego?

Po przeczytaniu tego pytania Dlaczego „~” wybrano do reprezentowania katalogu domowego? , kolejnym oczywistym pytaniem, jakie przyszło mi do głowy, było pytanie „dlaczego”. i „..” został użyty do przedstawienia katalogu bieżącego i katalogu nadrzędnego.

Wydaje się to teraz takie intuicyjne, ale z jakiegoś konkretnego powodu?

Wątpię, czy znajdziesz równie interesującą odpowiedź jak na pytanie o tyldę!

Nie było mnie tam, ale .. jest jak elipsa (...), co ma sens w takich kontekstach cd ../../../there. Ponadto, a zwłaszcza patrząc na starą klawiaturę terminala z tyldy, nie ma wielu odpowiednich znaków do tego celu. Nie musisz się też zmieniać .. Jest idealny.

Fakt, że w ukrytych plikach używany jest prefiks kropki, może być kolejnym powodem. Pliki ukryte nie są domyślnie wyświetlane na liście przez narzędzia takie jak ls, więc nie są zasadniczo zbędne .i ... Zbędne w tym sensie, że nie ma sensu brać ich pod uwagę wraz z innymi plikami - na pewno przydadzą się.

Jak się okazuje, że może mieć to wstecz ... z wikipedii :

Pojęcie nazw plików poprzedzone znakiem „.” powinien być ukryty jest wynikiem błędu oprogramowania w pierwszych dniach Uniksa. Kiedy specjalne „.” i do katalogu plików dodano wpisy katalogu „..”, zdecydowano, że polecenie ls nie powinno ich wyświetlać. Jednak program ls został błędnie napisany, aby wykluczyć każdy plik, którego nazwa zaczynała się od „.”, A nie tylko pliki o nazwie „.” lub „..”.

To okazuje się przydatne podczas programowania; ponieważ system zawiera. i .. w odpowiedzi na readdir()polecenia typu (i globusy powłoki), ignorowanie ich i ukrytych plików może być wykonane w ten sam sposób.

Inne zdanie na temat tej wartości użytkowej znajduje się w cytacie z wikipedii. Oczywiście cała historia może być apokryficzna ... trochę trudno uwierzyć, że np. Dennis Ritchie uznał, że sprawdzenie pierwszej postaci byłoby w porządku.

Nie zgadzam się z autorem, lepiej byłoby umieścić ukryte pliki konfiguracyjne w ich własnym katalogu niż nadać im uniwersalny prefiks. Prefiks jest znacznie bardziej elastyczny, umożliwiając stosowanie wewnętrznych instrukcji, takich jak .gitignorei .htaccess. Świadek, że tego rodzaju pliki pojawiają się razem, gdy są sortowane leksykograficznie - więc być może było to w końcu celowe .

^{Przeważnie ta sama odpowiedź, co @Panos 'na stackoverflow :}

Krótko mówiąc, ewoluowało z di dd( directory i directory's directory), które zostały stworzone przez użytkowników ręcznie. dstał się kropka , a ci, .a ..powstały najpierw przez mkdirnarzędzie (setuid po połączeniu katalogów zostało już dopuszczone przez zwykłego użytkownika), a później przez mkdir wywołanie systemowe.

Fragment wywiadu z Kenem Thompsonem (1989-09-06):

MSM : Ale dla użytkownika wyglądałby mniej więcej tak samo jak hierarchia katalogów.

Thompson : Nie, pierwszy był DG. W rzeczywistości nie było to nawet acykliczne. Jeśli rozumiesz system plików UNIX, to było… istniała lista I, która jest definicją wszystkich plików w systemie. A potem niektóre z tych plików to katalogi, które właśnie zawierały nazwę i numer I. Nic tam nie ogranicza tego drzewa. W rzeczywistości nie było to wcale, nie było hierarchiczne.

MSM : Rozumiem.

Thompson : I nie ograniczyliśmy go do drzewa. Eksperymentowaliśmy z różnymi topologiami. Skończyło się na tym, że zamieniamy się w konkretne i wymuszamy topologie, które w rzeczywistości były topologiami, które zostały przyjęte na podstawie konwencji z tego systemu. ... Za każdym razem, gdy tworzymy katalog, umownie umieszczamy go w innym katalogu o nazwie katalog - katalog , którym był dd. Nazywał się dd i że wszystkie katalogi użytkowników, a właściwie większość innych katalogów, użytkownicy utrzymują własne systemy katalogów, mieli wskaźniki z powrotem do dd, a dd zostało skrócone do kropki, a dd było dla katalogu katalog. Było to miejsce, w którym można było dostać się do wszystkich innych katalogów w systemie, aby utrzymać tę miskę do spaghetti. Mam na myśli to tuf w różnych formach, który był ściśle konwencją w tej implementacji DG tylko losowego zestawu katalogów i plików, zmuszony do typologii, którą utrzymywaliśmy. Kiedy zaczęliśmy pisać programy, takie jak sprawdzanie systemów plików i programy, blokowanie katalogów spaghetti i znajdowanie rozłącznych rzeczy, mam na myśli, że rozdzielisz coś i nigdy go nie odzyskasz, ponieważ wiesz, że go zgubiłeś. Problemy te stały się bliskie do przezwyciężenia, dlatego w następnej implementacji wymusiliśmy silniejszą typologię.