Как стать автором
Обновить

Комментарии 30

При переводе зарубежных слайдов следует уделять внимание специфике.


«Не папки — а каталоги» — ибо каталогов много, а папка у тебя один. Обычно по слову «папки» детектируют вендузятников и дуалбутчиков, истинные линуксоиды то, что в LC_ALL=C называют «directory», именуют «каталогами», и никогда не преминут случаем исправить невежд. ©

Похоже на запрещенные слова в армии или http://lurkmore.to/Крайний. Линуксоиды все равно общаются с виндузятниками, а кто-то даже пишет мультиплатформенный софт. Прямо таки табу.
Скорее на то, что определённые группы лиц более точны в [терминологии](https://en.wikipedia.org/wiki/Directory_(computing)#Folder_metaphor) чем другие.

Folder'ы есть и в linux, просто, в силу преобладающих интерфейсов взаимодействия с системой, у пользователей лучше формируется понимание чем одно отличается от другого.
Так бы и сказали что если досконально соблюдать терминологию то «папки» это в UI, а «директрии/каталоги» — на файловой системе, не все это знают, и я вот не знал, спасибо. (А не про родителей и виндузятников)

Про родителей и виндузятников это мнемоника, что бы лучше отпечаталось :)


Но, уловив суть, кое что вы упустили — директория имеет отображение именно в файловой системе и доступна через её интерфейсы. Папка — может быть реализована чисто инструментом на уровень выше. Пример — "последние использованные документы" в nautilus, вы не сможете получить к ней доступ через классический интерфейс fs. Точнее, сможете, но имя будет уже не столь дружелюбно и путь будет другой. Такие вещи как gvfs и fuse призваны сгладить различия, однако не всегда это имеет смысл/возможно.

В какой-то детской книжке сто лет назад видел аналогию: директория — это ящик, файл — это бутылка, а этикетка — это имя файла и другие параметры.
Так что фсе ваши директорииикаталогиипапки — пижонство.
Из орфоэпических соображений стараюсь не использовать слово «каталог», только «директория».
А по слову «директория» кого детектируют?
фанатов Керенского.
и Петлюры.
Спасибо, крутой материал
stderr — это разве ошибка вывода?

А ещё файловые дескрипторы можно передавать через unix сокеты. Ну и не забывайте, что select не работает с дескрипторами с номером выше 1024
> что select не работает с дескрипторами с номером выше 1024

Это вы выдумываете. Один вызов select'a не может обрабатывать более 1024 дескрипторов.
Нет, это вы придумываете. select использует маски, основанные на целочисленном представлении дескриптора. Один единственный дескриптор, попавший вне области допустимых значений, ломает работу селекта.
Нет, это просто вы используете операционную систему, где fd_set представляет собой битовую маску с лимитом, а значение 1024 захардкодено в инклюдах.

Системый вызов select, вообще говоря, может принять структуру любого размера. Её размер определяется первым параметром nfds. Попробуйте увеличить значение ulimit -n и использовать свой собственный fd_set увеличенного размера (либо переопределите __FD_SETSIZE).

Утверждается, что это приведёт к желаемому результату (поддержка дескрипторов с номерами больше 1024). Во всяком случае, во FreeBSD. В Linux же, скорее всего, функция отработает неправильно (лень проверять).

На самом деле, смысла в поддержке >1024 десрипторов нет, т.к. при таких количествах надо использовать epoll.

На самом деле, что бы вызвать бабочек в emacs уже есть команда :)

Да, прошу прощения, с перепутал с pselect.


Хотя, строго говоря, ни стандарт posix ни реализация как минимум linux не ограничивают select конкретно этим числом, есть только ограничение на то, что максимальный номер дескриптора ограничен константой заданной до вызова select. Но это не отменяет того, что я тут неверной информацией разбрасываюсь.

Конечно, это константу можно поменять, как и большинство других констант. Главный посыл моего сообщения был в том, чтобы на этот факт вообще обратили внимание. Впрочем, большинство программ редко открывают столько дескрипторов одновременно. Так что можно жить спокойно.
Удивительно, что в такой забавной форме можно подавать материал. Почерпнул для себя несколько новых фактов
Шрифт нечитаем, остальное норм.
Отчасти согласен, но основная проблема в размере картинок в посте. На самом деле они больше, если их открыть в оригинале, и там особых проблем с чтением нет.
Иллюстрации Джулии Эванс прекрасны!

Периодически почитываю ее блог.
НЛО прилетело и опубликовало эту надпись здесь
Перевод оформлен так же, как и оригинал
А что за «ошибка вывода» в переводе stderr? ))
Имелось ввиду «вывод ошибок», гугл-транслейт детектед. ))
Недавно пытался открыть в консоли (Mint, cinamon) директорию с длинным именем, содержащим кириллицу, терминал глючил. При нажатии «стрелки вверх» выводилась предыдущая команда, но если нажать второй раз то в строку дописывалась еще одна предыдущая, «бэкспейс» не работал.

У консоли есть какое-то ограничение на длину пути?
Консоль перекашивает при использовании русского языка, если она не поддерживает юникод. Проблем в том, что юникодные буквы могут кодироваться несколькими байтами, но при этом на экране отображаться одним символом. Если разработчики терминала не учитывали эту особенность, то расчёт переносов, отступов и прочих структурных элементов начинает сбоить, буквы затирают сами себя, и тому подобный глюкодром. Так что это можно назвать огрехами локализации. Читайте руководства по локализации для вашего дистрибутива — и настраивайте вручную, пока оно не перестанет глючить.

> У консоли есть какое-то ограничение на длину пути?

Есть ограничения, но не только у консоли, а у линукса в целом, сейчас я их опишу.

Во-первых, есть ограничения на максимальную длину имени одно файла (и директории соответственно). Это ограничение продиктовано способом записи метаинформации внутри файловых систем. Большинство популярных систем ограничивают длину имени файла в 255 байт. Что будет 255 символов для английского языка и вдвое меньше для русского, по причинам выше описанным. Но при этом директории с длинным именем в 255 байт можно произвольно вкладывать друг в друга.

Что самое удивительное, это работает, и можно переходить в поддиректории гигантской длины свободно. Но тут вступает в силу другое ограничение. Максимальная возможная длина полного пути — это 4095 байт. Ну как ограничение. С одной стороны никто не мешает построить файловую систему, содержащую хоть мегабайтный путь. Но у всех системных вызовов ограничение на длину пути в 4095 байт. Они просто не могут передать больше и обрезают. Что будет дальше, можете догадаться. Редкий программист занимается проверкой корректности переданного пути, так что многочисленные глюки вам гарантированы — можете поэкспериментировать.

Это ограничение связано с размером странички виртуальной памяти — для упрощения работы, чтобы не пришлось делить путь по нескольким виртуальным страницам. Не знаю, насколько сильно он прибит гвоздями. Размер виртуальной страницы можно сконфигурировать. Может быть и PATH_MAX тоже.
Ух ты, спасибо за развернутый ответ. Насколько я разобрался мой дист может в латиницу, но не полноценно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий