Чи вважається найкращою практикою не використовувати великих літер у іменуванні файлів?

28

Люди кажуть, що не слід використовувати пробіли в іменуванні файлів Unix. Чи є вагомі причини не використовувати великі літери у назвах файлів (тобто File_Name.txtпроти file_name.txt)? Або це лише питання особистої переваги?

filenames

— DD343
джерело

Ви можете використовувати шапки, але як стандарт не використовуйте. Просто використовуйте маленькі літери та _ так file_name.txt добре.

— Шабір А.

9

Є деякі речі Unixy, які використовують назви файлів з великої літери ... деякі приклади включають Makefile, INSTALL, CHANGELOG і, звичайно, шановну README.

— Томас

PSR-2 - стандарт фактичного іменування світу PHP, який працює більшістю в Linux, використовує camelCase php-fig.org/psr/psr-2

— jdog

46

Люди кажуть, що у назві файлів Unix не слід пропускати пробіли.

Люди говорять багато речей. Є деякі інструменти, які можуть накрутити, але, сподіваємось, їх наразі мало, оскільки простори - це вірус, розповсюджений гігантськими споживчими корпораціями ОС, і цього неможливо уникнути.

Пробіли створюють незрозумілі вказівки назви файлів у командному рядку тощо. Ось про це. Єдиними категорично забороненими символами в * nix системах є NUL (не хвилюйтеся, це не на вашій клавіатурі чи комусь іншому) і /, оскільки це роздільник шляху. ¹ Окрім цього все, що стосується. Окремі елементи шляху (назви файлів) обмежені 255 байтами (можливе ускладнення, якщо ви використовуєте розширені набори символів), а цілі шляхи - до 4 KiB.

Або це лише питання особистих уподобань

Я б сказав, що так і є. Більшість DE, здається, створити вбивання капіталізованих каталогів в вашому $HOME( Downloads, Desktop, Documents- Dдуже популярний), так що немає нічого дивно про це. Існують також дуже звичні традиційні файли з великими літерами, такі як .Xclientsі .Xauthority.

Цінність використання великих букв на початку полягає в тому, що, перераховуючи лексикографічно, вони перейдуть до речей з нижнього регістру - принаймні, з багатьма інструментами та залежно від місцевості.

Я шанувальник справи верблюда (ака. CamelCase) і використовую його з назви файлів, наприклад, /home/goldilocks/blueSuedeShoes- неважливо, що там є. Безумовно, це питання особистої переваги, але це ще не викликало у мене горя.

Файли класів Java, як правило, містять великі літери, тому що назви класів Java. І звичайно, не будемо забувати NetworkManager, навіть якщо хтось із нас волів би цього.

^{1. Існує набагато більш обмежений, рекомендований POSIX "Портативний набір символів назви файлів" , який не включає пробіл - але він включає верхній регістр! POSIX також визначає більш загальне обмеження стосовно "символу косої риси та нульового байта" в іншому місці цього ж документа . Це відображає або відображається на традиційних традиціях .}

— золотинки
джерело

5

Міа: "Це факт?" Вінсент: "Ні, це не так, це просто те, що я почув". Міа: "Хто вам це сказав?" Вінсент: "Вони". Міа: "Вони багато говорять, чи не так?" Вінсент: "Вони звичайно так роблять".

— corsiKa

4

« Значення з спекулюючи що - то на самому початку, що коли перерахований лексичний [...], вони прийдуть перш , ніж все інше.» - Звичайно, це працює тільки тоді , коли більшість з імен файлів в нижньому регістрі, що дає вам привід для резервних ковпачків ( принаймні провідні шапки) для ваших READMEs і Makefiles тощо.

— Blacklight Shining

4

На багатьох клавіатурах ctrl-space або ctrl- @ або alt-0 буде введено NUL.

— сумнівним

2

@dodgethesteamroller Я вважаю, що ви прямо помиляєтесь щодо косої риски вперед (а точніше, байта зі значенням 0x2F) у ext *. Насправді я не вірю, що він навіть потрапить у файлову систему; шар VFS забороняє його незалежно від зберігання резервного копіювання.

— zwol

3

просто не використовуйте пробіли у назвах імен та директорій. навіть якщо ваша система технічно це дозволяє, це викличе лише ваше горе. Замість цього використовуйте "_" символ підкреслення.

— SnakeDoc

9

Однією з причин уникати заголовків у файлах файлів є те, що порядок сортування в Unix чутливий до регістру, тому файли, що починаються з великої літери, з’являться поза порядком. Ось причина Makefile, яку зазвичай називають великою літерою M- це один із файлів, який ви хочете побачити першим, без прокрутки / пропускання вниз по жолобі a-l.

Це говорить про те, що ви можете зробити набагато гірше щодо імен файлів:

використання пробілів порушить деякі погано написані програми та сценарії, які не цитують імен файлів належним чином
запуск імені файлу з символом a -може спричинити проблеми, оскільки багато програм будуть бачити його як опцію командного рядка замість імені файлу (наприклад rm -r, не буде видалено названий файл -r).
запустивши ім'я файлу зі .знаком " a" , приховає його від багатьох утиліт та глобальної оболонки (наприклад rm *, не видалятиме файли, як .config)
використання спеціальних символів, таких як |<>*?і навіть недрукувальних символів, таких newlineяк технічно можливо, але може порушити сценарії / програми, схожі на символи пробілу. Різниця полягає в тому, що простір символів часто використовується, тому програмісти прагнуть перевірити свої програми на нього, тоді як менш популярні символи часто залишаються неперевіреними.

— Дмитро Григор’єв
джерело

4

Це, як правило, вже не відповідає дійсності, сортування в сучасних локальних місцях, як правило, не чутливе до регістру, і багато інструментів і глобулів оболонок шанують локаль за сортування імен файлів.

— Стефан Шазелас

2

Ви хотіли сказати: rm *не видалять файли типу .config?

— Wildcard

1

@Wildcard не дуже, але, можливо, ваш приклад є більш реалістичним, ніж мій. Моя думка полягала в тому, щоб показати, що назви файлів, починаючи з крапки, не захищені від глобалізації, навіть якщо користувач чітко вказав цю крапку.

— Дмитро Григор’єв

1

@DmitryGrigoryev, ні вони не є. Спробуйте ls -ald. ?? * у будь-якому каталозі, який містить крапки.

— Білл Барт

1

Я вважаю, що було б доречніше сказати "Якщо ви вирішите використовувати великі літери в іменах файлів, ви повинні мати на увазі той факт, що порядок сортування в Unix (іноді) чутливий до регістру". Користувач може захотіти такої поведінки Makefileі READMEє ідеальними прикладами цього. Зауважте також, що цей ефект є незначним, якщо літера не є першою літерою в імені, тож не дуже важливо, якщо ви використовуєте camelCase. Звичайно, ви можете здивуватися anOctagonраніше angle, але принаймні вони будуть разом у списку.

— G-Man каже: "Відновіть Моніку"

6

Якщо ви збираєтесь взаємодіяти з середовищем Windows, вам слід уникати великих літер, тому що Windows все зменшить. Частіше це проблема йде іншим шляхом; посилання на Page_2.htmlпошук знайдеться page_2.htmlв Windows, але в Unix не вдасться.

— NL_Derek
джерело

10

Що це не так. Всі NTFS, VFAT і exFAT не залежать від регістру, але зберігають регістри, тобто вони ігнорують регістр з метою пошуку, але тим не менш зберігають регістр. Те саме стосується HFS +, файлової системи за замовчуванням на OSX. NTFS навіть має простір імен POSIX, який працює точно так само, як і всі інші Unices, тобто дуже довгі назви файлів не інтерпретованих октетів, з єдиними NULта /забороненими.

— Йорг W Міттаг

5

Більш того, "нечутливий до регістру, але збереження регістру" - це ще один спосіб сказати "здатний безшумно перезаписати файл A, оскільки його назва відрізняється лише у випадку з файлом B" (або навпаки, залежно від того, який був збережений пізніше). Іншими словами, якщо ви використовуєте оболонку * nix для доступу до спільного доступу до NTFS, cat > Fooфайл буде замінено foo. Така поведінка може бути несподіваними і заплутаним , якщо ви звикли справу , що зберігають і чутливі до регістру файлових систем , такі як доб *.

— dodgethesteamroller

1

@ JörgWMittag Якщо я не помиляюся, NTFS не чутливий до регістру, це просто те, що Windows працює таємничими способами.

— Cthulhu

1

@Cthulhu: AFAIK, NTFS має чотири різні простори імен, в яких можна створювати імена для файлів. (Я не знаю, чи може один файл мати ім’я у кількох просторах імен.) Простір імен "DOS" (8.3, нечутливий до регістру), "довгий" простір імен (нечутливий до регістру, зберігає регістр, UTF-16), спеціальний простір імен для «довгих» короткі імена, тобто імена яких справа має бути збережено , але вписується в 8.3, і простір імен POSIX (потік відмінних октетів \0і /, чутливий до регістру). Принаймні так я це пам’ятаю. Але я згоден, що це свого роду безлад. Є додаткові обмеження у…

— Jörg W Mittag

1

… Ядро та ще більше обмеження в API (насправді існують різні API різних епох з різними обмеженнями), є обмеження через сумісність з DOS та FAT, є обмеження в інтерпретаторі команд, є обмеження в ( графічна) оболонка, а в Провіднику є обмеження. І часто неможливо достовірно визначити, звідки йде обмеження. Це божевілля. Одного разу мені вдалося створити файл за допомогою Провідника , який неможливо було відкрити, скопіювати, перемістити, перейменувати чи видалити за допомогою будь-якого інструменту, який я спробував. Це в основному залишилося на…

— Jörg W Mittag

4

Однією з причин уникнення обмежень є те, bashщо вкладка s табуляції залежить від регістру (принаймні, за замовчуванням) - це все одно відключає мене кожного разу, коли я опиняюся перед bashконфігурацією за замовчуванням. Звичайно, є й інші популярні оболонки, але це в поєднанні з тим, що bashоболонка для входу за замовчуванням для багатьох ОС означає, що за замовчуванням часто буває залежно від регістру. Використання іменних файлів із малих літер тут значно спрощує речі.

— Блискуче світло
джерело

2

echo set completion-ignore-case On >> ~/.inputrcможе трохи допомогти, принаймні у власній системі.

— wchargin

1

Мені не зрозуміло, в чому полягає ця відповідь - хіба що ви можете забути, як ви "написали" ім'я файлу. Наприклад, якщо ви створили файл з назвою Fooта пізніше введіть cat f(Tab), він не вдасться. Але те ж саме відбувається , якщо ви друкуєте cat foo, cat Foobarабо cat Fu- той факт , що ви будете мати проблеми з доступом до файлу , чиє ім'я ви не пам'ятаєте правильно на насправді не має нічого спільного з автозаповненням.

— G-Man каже: "Відновіть Моніку"

@ G-Man Touché. Тим не менш, використання найменших імен файлів означає, що вам потрібно пам’ятати про них менше.

— Blacklight Shining

3

Оскільки NL_Derek відкрив цю банку з хробаками, але не сформулював її належним чином, я скажу так:

Добре використовувати великі літери, але вам слід уникати створення файлів (у тому самому каталозі), які відрізняються лише залежно від регістру , наприклад, File_Name.txt і file_name.txt , оскільки

Якщо ви якось зробите каталог доступним для системи Windows, він не зможе отримати доступ до обох файлів. Ймовірно, ви зможете отримати доступ лише до того, який з’явиться першим у каталозі, незалежно від того, яке ім’я ви використовуєте. (За винятком випадків: він може надати вам доступ до них як FILENA~1.TXTі FILENA~2.TXT - введіть, dir /xщоб побачити, яке коротке ім'я (якщо воно є) походить із тим довгим ім'ям.)
Якщо файлова система насправді є файловою системою Windows (наприклад, встановлена з файлової системи exFAT або NTFS з сервера NFS під управлінням Windows), два імена (ймовірно) не будуть дозволені співіснувати. Наприклад, якщо ви робите , і ви можете в кінцевому підсумку з одним файлом, в якому міститься висновок .cmd₁ > foocmd₂ > Foocmd₂
Аналогічно, якщо ви коли-небудь передасте файли в систему Windows, ці два імена (ймовірно) не будуть дозволені співіснувати. Наприклад, якщо ви створили архів (наприклад, zip), що містить два файли, і витягли його в системі Windows, другий файл, ймовірно, замінить перший. Те саме, якщо ви перенесли їх у вікно Windows з FTP або щось подібне.

— G-Man каже "Відновити Моніку"
джерело

Не тільки Windows, але й декілька інших ОС (VMS, я думаю, CP / M звичайно, інші ...)

— Toby Speight

3

Крім технічних причин, у мене є практичний аспект до цього. Якщо дотримуватися малих літер, то пошук буде простішим, якщо ви не любите використовувати grep -i або lociraj -i. Іноді навіть camelCase може бути заплутаною, якщо доводиться використовувати рядок однотипних слів, як у сховищіNYCDCPrimary. Отже, я вважаю, що найкраще дотримуватися малих літер і перець їх підкресленнями або дефісами для зручності читання, як-от сховище_nyc_dc_primary.

— Заскакуючий Зайчик
джерело

snake_case легко на очах - storageNycDcPrimaryі StorageNycDcPrimaryїх обидва дивно читати.

— go2null

1

Я вважаю, що найкращою практикою є уникати використання великих літер та пробілів у назви файлів.

Деякі кажуть, що вони не згодні, але це питання або те, що я називаю релігійними переконаннями : важко обговорити і погодитись. Ті, хто не погоджується, кажуть, що більшість інструментів тепер є столицями та просторами: вони праві, але це не питання.

Правильне питання - скільки потрібно використовувати великих літер та пробілів у назви файлів. На це питання, за винятком випадків, коли я програмую на Java, відповідь, як правило, весь час: мені не потрібні великі літери та пробіли у моїх іменах . Усі пробіли я замінюю символом підкреслення ( _) або знаком мінус ( -), і тому я не використовую чохол верблюда (ака. CamelCase) всупереч деякій іншій релігії.

Багато людей дзвонили мені на дурниць за те, що вони роблять і навчають, що - деякі з них все ще роблять - деякі з них натрапили на інструмент, який не є зручним для капіталу / простору, і прийшли до мене, сказавши, що я правий і що вони повинні мене слухати. Робіть все, що завгодно , і якщо ви використовуєте великі літери та пробіли у назви файлів, я сподіваюся, що ви ніколи не заїдете на погано написаний інструмент. Однак, якщо ви подорожуєте на такому інструменті, сподіваємось знову, це не складе труднощів для виправлення та не обійдеться вашому бізнесу та / або вам багато грошей та / або часу. Але якщо в кінцевому підсумку виникають погані наслідки, ви пам’ятаєте, що деякі раніше говорили вам, що використання великих літер та пробілів у назви файлів - це погана практика.

І останнє, якщо ви хочете уникнути всіх проблем , жодних спеціальних символів у назви файлів (лише малі літери, цифри, підкреслення та мінуси [1]). Цей список небажаних символів також включає всіх символів, які не мають права (так, французи та інші не англійські люди - і я один з них - жоден із них: à, â, ä, ç, é, ..., ö, æ, œ , ...). Це також стосується багатьох інших речей, включаючи логін та пароль . Я дозволю вам здогадатися, що трапиться, коли ви введете цитату чи подвійну цитату ( 'або ") у логін або пароль, якими обробляється bash-скрипт, не написаний підтвердженим sysadmin ....

[1]: може бути , ми могли б розширити , що ~, @, #і деякі інші, але це шукає неприємності (і так , я знаю про EMACS файлів ...).

— jfg956
джерело

1

Останнє - це те, з чим повинна працювати система автентифікації, а не користувач, який придумує пароль. Якщо система обмежує набір дозволених символів у паролях, це погана система.

— Blacklight Shining

Ну а обмеження символів у паролі є предметом для дискусій: li1, oO0, ... залежно від прихильності, важко спілкуватися. Дехто би сказав, що пароль не слід повідомляти, але ключ WiFi - це такий собі пароль, який я повідомляю своїм друзям, коли вони в мене є ...

— jfg956

Це усвідомлений вибір з вашого боку - уникати використання деяких символів, а не обмежень, вбудованих у систему (у цьому прикладі стандарти Wi-Fi, реалізація AP та клієнта тощо). Якщо ви використовуєте в якості пароля рядок випадково вибраних символів, ви можете поліпшити читабельність, використовуючи (або заохочуючи одержувачів використовувати) шрифт монопростіру, або просто використовуючи більш чіткі гліфи, якщо ви їх пишете рукописним текстом L, верхній регістр I та цифра 1; менший O, менший O, кругла велика O, нарізана або пунктирна цифра 0; тощо). Крім того, ви можете використовувати парольну фразу.

— Blacklight Shining