Докато повечето от нас виждат само нормални имена на файлове и папки на нашите системи Windows, други хора може да са срещнали нещо малко по-неочаквано - имената на файловете и папките с точка пред тях. Защо се случва това? Днешната публикация "SuperUser Q & A" има отговора на един много любопитен въпрос на читателя.
Днешната сесия за въпроси и отговори ни идва с любезното съдействие на SuperUser - подразделение на Stack Exchange - обединяване на уеб сайтове с въпроси и отговори.
Снимката е предоставена от Domiriel (Flickr).
Четецът на SuperUser Нико Белич иска да разбере защо някои имена на файлове и папки в Windows имат точка пред тях:
Например, в Моите документи в моята Windows система Намерих следните папки:
- .ssh
- .subversion
Дали това е някаква конвенция за именуване, за която не знам?
Защо някои имена на файлове и папки в Windows имат пред тях точка?
Слуховият сътрудник на SuperUser има отговор за нас:
Тази конвенция за именуване идва от Unix-подобни операционни системи (като Linux или OSX), където това означава a скрит файл или указател, Той работи навсякъде, но основната му употреба е да скриете конфигурационните файлове в домашната ви директория (т.е. ~ / .cache / или ~ / .plan) Те често се наричат точкови файлове.
Точкови файлове може по някакъв начин да се нарече традиционен Unix, еквивалентен на AppData в Windows. Междувременно, много програми на Linux се променят, за да следват спецификацията на основната директория на XDG, като преместват конфигурацията си ~ / .Config / и други данни до ~ / .Cache / и ~ / .Local / дял /, Това го прави по-сходен AppData \ Roaming и AppData \ Local.
Имате такива .ssh и .subversion директории на Windows, защото сте използвали някои програми (по-точно OpenSSH и Subversion), които са пренесени да използват API на Windows, а не POSIX, но не са били коригирани за някои други конвенции на Windows.
Понякога тази адаптация се прескача умишлено, за да направи живота по-лесен за хора, които използват подобна на Unix среда като Cygwin на техните системи Windows. Например, Cygwin инсталира стандартния набор от Unix-подобни инструменти като LS, който игнорира Windows скрит флаг и само почита точков файл имена. Също така е по-лесно да синхронизирате конфигурациите между компютрите на Windows и Linux / BSD / OSX на дадено лице, ако е споделено на едно и също място.
Тези файлове обикновено се намират в домашната директория на потребителя (т.е. /home/name/.ssh на Linux или C: \ Users \ името \ .ssh в Windows 7 и по-нови). Много рядко е да се включат в него Документи или Моите документи поддиректории (в крайна сметка не съдържат документи).
Както Роб Пик пише в Google+, това е случайна функция:
Много отдавна, тъй като дизайнът на файловата система Unix е бил разработен, записите . и … за да се улесни навигацията. Не съм сигурен, но вярвам … влезе по време на преработването на Версия 2, когато файловата система се превърна в йерархична (имаше много различна структура в началото). Когато някой напише LS, тези файлове обаче се появиха, така че Кен или Денис добавиха прост тест към програмата. Тогава беше в асемблер, но въпросният код беше еквивалентен на нещо подобно:
- ако (име [0] == '.') продължават;
Това твърдение беше малко по-кратко от това, което трябваше да бъде, което е:
- ако (strcmp (име, ".") == 0 || strcmp (име, "...") == 0) продължава;
Но хей, беше лесно и се получиха две неща.
Първо, беше определен лош прецедент. Много други мързеливи програмисти въведоха бъгове, като направиха същото опростяване. Действителните файлове, започващи с периоди, често се пропускат, когато трябва да се отчитат.
Второ, и още по-лошо, идеята за а скрит или точков файл беше създаден. В резултат на това по-мързеливи програмисти започнаха да пускат файлове в домашната директория на всички. Нямам инсталиран много софтуер на компютъра, който използвам, за да пиша това, но домашната ми директория е около сто точкови файлове и дори не знам кои са повечето от тях или дали те все още са необходими. Всяко оценяване на името на файла, което минава през домашната ми директория, се забавя от тази натрупана утайка.
Имате ли нещо, което да добавите към обяснението? Звучи в коментарите. Искате ли да прочетете повече отговори от други потребители на Stack Exchange? Вижте цялата тема на дискусията тук.
