А что .txt?

Это пережиток DOS с его 8.3 схемой наименования файлов. Я предпочитаю filename.plaintextfile.

Чтобы сразу было видно, что это плейнтекст-файл?

.txt формат

Зачем ты называешь это форматом?

Поправьте меня!

Расширение нужно мобильному дропбоксу, например. К тому же оно позволяет юзеру на глаз отличить текст от бинаря и указывает на то, что текст неструктурирован, в отличие от md, yml, csv и прочего.

Поправьте меня!

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

Не всем файлам нужно расширение. Увидя «LICENSE», «Makefile» и «fstab» ты поймёшь, что это.

Если ты об этом.

Зачем нужен .txt. формат

ставь вопрос шире, зачем ваще нужны длинные имена файлов и директорий.

1, 2, 3… и вперед, что за дичь с буквами навыдумывали?

Зачем нужен .txt.

«Это фамилие такое…» ©.

Это потому что ты уже с ними знаком. А вот если бы не был знаком? Сходу было бы не понятно, fstab это что-то текстовое или бинарное, пока его не откроешь.

Кстати, у неверной простановки *.txt расширений есть и другая сторона медали. Реальный пример из жизни: CMakeLists.txt

Внутри этого файла вовсе не Plain Text, а структурированный DSL, который редакторы должны подсвечивать и парсить. Спрашивается, нахрена идиоты из Kitware (разработчики CMake) прилепили к нему *.txt? При этом файлы, расширяющие скрипт сборки, с абсолютно таким же синтаксисом, они уже рекомендуют помечать расширением *.cmake, почему нельзя было сразу сделать Build.cmake или нечто подобное? Что за рак вообще?

Вот в Gradle или Scala всё чётко, логично и ясно:

• build.gradle – Дефолтный DSL у Gradle, расширение Groovy.
• build.sbt – DSL для SBT на основе Scala.
• build.gradle.kts – DSL у Gradle на основе Kotlin Script.

Сходу было бы не понятно, fstab это что-то текстовое

В /etc-то?

у неверной простановки *.txt расширений

Да я в общем-то о том же. В случае с fstab можно было бы добавить разве что сферическое .conf, которое как правило вне контекста ни о чём не говорит.

+1

А насчёт отсутствия суффикса, как-то так повелось, что набранные КАПСОМ имена по умолчанию воспринимаются как тестовые файлы.

Но кроме ограниченного списка известных файлов, не стоит так делать.

Залитый в облако txt можно отредактировать/посмотреть онлайн. Ноунейм файл нет.

У меня текстовый редактор настроен так, что при открытии файлов с расширением .txt автоматически включается перенос строк.
А у файлов без расширения .txt автоперенос строк выключен по умолчанию, и чтобы просмотреть длиную строку, нужно промотать горизонтальный скролл.
Это очень удобно: мне не нужно внутри редактора нажимать кнопку wrap/unwrap в зависимости от содержимого.
Расширение .txt как бы говорит редактору «внутри меня простой поток длинного текста, без какого-либо форматирования».
А просматривать исходники программ, конечно же, удобнее без автопереноса строк.

Конечно не нужен - лучше каждый раз когда тебе 2 слова нужно прочитать или написать ждать по пол часа, пока либраофис загрузится!

А где ещё ты будешь хранить информацию о типе файла (что это не ELF, например), если поле mime-type в файловые системы до сих пор не завезли?

ляликсе

КЛБ!

все текстовые процессоры хавают файлы в формате «textfile» без каких-либо расширений, так же и cat

А челавекам лучше хавается с txt.

видно, что это плейнтекст-файл

Так ведь плейнтекст это дефолт.

На своих текстовых файлах всегда ставлю .txt
Вообще это правильно. Не нужно влезать внутрь файла и парсить сигнатуры, чтобы определить тип файла.

Увидя «LICENSE», «Makefile» и «fstab» ты поймёшь, что это

На самом деле - нет, это никак не даст понять, что там в лицензии: чистый текст или может быть Markdown?

Makefile и fstab тоже были бы с расширениями лучше - по ним можно было бы понять в какой программе можно из синтаксис открыть, подсветить, и валидировать, предже чем они наломают дров.

неправильный fstab вообще может привести к «ничего не загружается». Но к ниму ни валидатора нет, и синтаксис непонятно какой. Он описан текстом, но валидаторов под рукой нет.

чистый текст или может быть Markdown?

Во-первых, какая разница? Во-вторых, я лично никогда не видел лицухи в маркдауне.

по ним можно было бы понять в какой программе можно из синтаксис открыть

Любой нормальный редактор тебе мейкфайл подсветит просто по названию файла, а в fstab валировать попросту нечего.

а в fstab валировать попросту нечего.

У меня vim понимает его формат и подсвечивает ошибку, если, например dump или pass цифру убрать. Если лишнюю в конец строки дописать - не выделяет её как предыдущие (видимо лишние значения не используются).

Ну и внутри строки там попробовал вносить изменения - vim знает какие параметры корректны, а какие нет, выделяет ошибку, если лишний пробел запихнуть.

Но в vim, скорее всего, специальный костыль, что эта подстветка используется только для файла /etc/fstab. Это же наоборот неудобство для файла без расширения. Он же не подсветит так же /etc/fstab-backup или /etc/backup/fstab?

я лично никогда не видел лицухи в маркдауне

Ты видимо редко ходишь на GitHub.

Но там лицензия в Markdown обычно обозначается как License.md, и это правильно.

https://github.com/search?l=&q=filename%3ALicense.md

Да, не подсветит. Но то был ответ Ведьмаку, что таки там, в fstab, есть что валидировать. И мэйкфайл тоже «костылём по названию» подсвечивается.

Согласен, что неудобство, но тут уж нашло легаси названия fstab на современное желание валидации. И без потерь этот конфликт не разрешить. Вот и закостылили.

Да, даёшь fstab.txt!

Вот это как раз было бы ошибкой, как и в случае с CMakeLists.txt

На прошлом месте работы там хостились. Куда уж чаще.

Видимо новая мода какая-то.

А отрендерю-ка я лицензию в жопег…

Для fstab мне кажется нет подходящего расширения описывающего его синтаксис. Ну типа fs.tab? Тогда что есть .tab? Подходит ли сюда mtab?

А мейкфайлы, симейклисты действительно можно было бы иметь со специальными расширениями для этих файлов.

В AV1, секунд по 20 абзац, либо бегущей строкой, а то и вовсе как в Звёздных Войнах.

main.fstab, backup.fstab, slave.fstab…

Ну… ок. Правда часто ли требуется больше одного?

DOS-LEGACY.

Никогда. Если действительно нужен бекап на месте, адекваты юзают git.

Для хранения неструктурированного текста разумеется. Например, в случае nlp задач я в .txt исходные данные перегоняю, если мне не нужно учитывать какие-то специфические штуки, вроде выделения текста юзером.

А не на гэбню ли ты работаешь, дружок?

Ну вообще, Debain, если что-то меняет, любит делать копию с дописанным dist в конце. А так, я просто предположил, как тогда fstab можно-было бы расширить с «временно подключаемыми» дисками, или чем-либо ещё. А так сейчас это монолит со старинным синтаксисом из набора непонятных опций

Вообще-то git не является средством для бэкапов.

Тебя не смущает оксюморон «локальный бекап»? Гит прекрасно годится для фиксации изменений конфига и отката при необходимости.

Тебя не смущает оксюморон «локальный бекап»?

Это не оксюморон. Локальный бекап на случай локального факапа.

В том смысле в котором luke понял слово «бекап» это таки оксюморон. Иначе бы он не сказал:

Вообще-то git не является средством для бэкапов

Git поможет такие факапы отловить, даже если что-то неладное ты заметишь очень нескоро и поправишь по пути конфиг ещё пяток раз.

Окей, спор про определения.

Вообще в данном случае я бы попробовал использовать снапшоты, ежели это возможно, по типу как в Guix.

Зачем нужен .txt.

Потому что в общем случае невозможно распознать тип файла по содержимому. Может быть бинарник, у которого начальная часть находится в диапазоне ASCII. Типы файлов должны явно храниться. Haiku для этого использует MIME-типы в xattr атрибутах файлов, но у такого метода свои проблемы: легко потерять атрибуты при архивации или переносе на файловую систему без поддержки атрибутов.

main.fstab, backup.fstab, slave.fstab…

ИМХО, если уж формат fstab уникален, то лучше не расширение вводить и ждать его поддержки в редакторах, а менять формат fstab на какой-нибудь распространённый и использовать расширение этого распространённого. Тогда не нужно костылить в редакторах, получаем какую-то унификацию, но да, легаси ломается.

Но и в вашем варианте оно ломается (название файла).

«tab» может означать «table» (таблица).

• В CSV — запятые.
• В TSV — табуляция.
• В fstab и mtab — табуляция или пробелы.

Только вот поддерживаются комментарии; внутри записей в fstab, mtab и crypttab — списки с опциями через запятую; в crontab седьмое поле идёт до конца; в inittab и quotatab поля разделены двоеточиями… В blkidtab… это как вообще? DEVNO, TIME, содержимое элемента и т. п. — это колонки?

Ну, такая сложная «поломка» решается довольно просто: ln

а вот привести все стандартные «легаси» вещи к одному формату - это жесть та ещё

А зачем тебе признак x на файлах? Это лишнее, надо всегда догадываться что исполняемое. Каждый раз. Потому что надо превозмогать. Потому что ты бездельник и маешься хернёй.

Ну а смысл? Иметь разножопицу форматов, прикрутить линки с расширениями и ожидать, что авторы редакторов и прочие начнут поддерживать эти расширения и форматы, которые используются в единичных файлах? Это путь куда?

Уж лучше всё в какой-нибудь csv перепилить, легаси форматы тоже читать, но объявить депрекейтед и к удалению через 5 лет.

Да, смысла всё это причёсывать может и нет. Плюс единственный - упрощение валидации. А головной боли с кооперацией авторов софта, поддержкой легаси и прочим - дофига.

В конфигах, как праило, и формат описан - редактируй аккуратно и всё будет хорошо.

Не. А что, там тоже в txt? Круто, не знал.