Dlaczego listy katalogów zawierają katalog bieżący (.) I katalog nadrzędny (..)?

Question

Ilekroć wyświetlam zawartość katalogu z funkcją taką jak readdir, zwrócone nazwy plików zawierają również "." i "..". Podejrzewam, że są to zwykłe linki w systemie plików i dlatego nie można ich odróżnić od rzeczywistych plików, ale zawsze muszę je odfiltrować, ponieważ nie są rzeczywistymi obiektami w katalogu, który wymieniam. Czy istnieje dobry powód, aby funkcje takie jak readdir je uwzględniały? Czy niektóre systemy operacyjne lub systemy plików zawierają więcej lub różne nazwy plików wirtualnych? Czy istnieje lepszy sposób na ich filtrowanie poza wykonaniem porównania łańcuchów z "." i ".."?

Aktualizacja: dziękuję wszystkim za odpowiedź. Sądzę, że zawsze uważałem, że takie rzeczy jak ./ i ../ były zwykłymi konwencjami, którymi można się posłużyć, szukając i zastępując. Uważam, że jest to nieco zaskakujące, ale prawdopodobnie bardziej wydajne i przejrzyste, aby stały się częścią samego systemu plików.

Pozostaje jedno pytanie: od. i .. są arbitralne nazwy dla tych linków, czy istnieją systemy plików, które używają różnych?

Answer 1

. i .. są w rzeczywistości twardymi linkami w systemach plików. Są one potrzebne, aby można było określić ścieżki względne na podstawie pewnej ścieżki referencyjnej (należy rozważyć "../sibling/file.txt"). Ponieważ te twarde łącza faktycznie istnieją w systemie plików, ma to sens, aby readdir mógł Ci o nich powiedzieć. (właściwie określenie hard link oznacza po prostu jakąś nazwę, która jest nie do odróżnienia od rzeczywistego katalogu, do którego się odnosi: oba wskazują na ten sam inode w systemie plików).

Najlepszym sposobem jest po prostu strcmp i zignorowanie ich, jeśli nie chcesz ich wymieniać.

Answer 2

Jednym z powodów jest to, że bez nich nie można uzyskać dostępu do katalogu nadrzędnego. Lub zdobądź uchwyt do bieżącego katalogu.

Bez nich nie możemy robić takie rzeczy jak: ''

./run_this 

Rzeczywiście, nie mogliśmy dodać do $ PATH, co oznacza, że ​​nigdy nie mogliśmy wykonywać plików, które nie były jeszcze w ścieżce.

Answer 3

Są to normalne katalogi, są "twardymi linkami" do bieżącego katalogu i katalogu powyżej. Są one obecne we wszystkich katalogach (nawet na poziomie katalogu głównego, gdzie .. jest dokładnie taki sam jak .).

Podczas korzystania ls można odfiltrować . i .. z ls -A (uwaga kapitału -A).

Kiedy stosuję polecenie do wszystkich plików z kropkami, ale nie . lub .., często używam .??*, który dopasowuje tylko plik dot o nazwie trzy lub więcej znaków.

touch .??* 

Uwaga Ten wzór obejmuje również dowolny inny plik, który zaczyna się od kropki i ma tylko dwa znaki (np .x), ale te pliki są rzadkością.

Podczas korzystania z programatycznych programów do sortowania plików, takich jak readdir(), muszę ręcznie wykluczyć . i ... Ponieważ te dwa pliki mają być na początku listy zwróconej przez readdir() można to zrobić:

@files = readdir(DIR); 
for (1..2) { shift @files; } # get rid of . and .. 
# go on with your business 

Answer 4

są zgłaszane, ponieważ są one przechowywane w katalogu aukcji. W ten sposób zawsze działają unice.

Answer 5

Ponieważ w systemach typu Unix, polecenia do katalogowania zawierają te i używasz ich do przechodzenia w górę i w dół w hierarchii systemu plików.

Coś takiego jak grep { not /^.{1,2}\z/ } readdir HANDLE powinno zadziałać.

Answer 6

nie ma powodu, dla którego skanowanie katalogu powinno zwracać te nazwy plików.

Answer 7

Mam podejrzenie, że są to po prostu normalne linki w systemie plików i dlatego nie do odróżnienia od rzeczywistych plików

Są. Chociaż system plików można postrzegać jako hierarchię "folderów" "zawierających" foldery, w rzeczywistości jest to drzewo podwójnie połączone , z katalogami będącymi węzłami i plikami będącymi liśćmi. Tak więc, . i .. są potrzebne do uzyskiwania dostępu do liści bieżącego węzła i do przechodzenia przez drzewo, i są tym samym, co wszystkie inne łącza.

Po wywołaniu readdir otrzymasz wszystkie miejsca, do których możesz bezpośrednio przejść z bieżącego węzła. Jeśli nie chcesz wyświetlać miejsc, które postrzegasz jako "up", musisz je sam uporządkować. Powinieneś napisać do tego niewielką funkcję, być może nazwaną readdir_down. Nie wiem, w jakiej kolejności readdir wyświetla listę katalogów, ale być może po prostu wyrzucisz pierwsze dwa wpisy.

) Jest to pierwsze przybliżenie, istnieją również "twarde linki", które sprawiają, że drzewo jest faktycznie siecią.

Answer 8

Pierwotnie były to twarde linki i liczba specjalnych przypadków w kodzie systemu plików. i ... były minimalne. Nie dotyczy to jednak wszystkich nowoczesnych systemów plików.

Ale konwencje zostały ustanowione tak, że nawet systemy plików, w których te dwa wpisy katalogów faktycznie nie istnieją, nadal zgłaszają swoje istnienie poprzez API takie jak readdir. Zmiana tego oznaczałaby teraz złamanie wielu kodów.