Если я, на пример, уберу расширения с видео, картинок и тп. то тогда мне обязательно придется картинки сложить в картинки, видео в видео и тп. И все равно оно постепенно все перепутается, засрется и будет полный бардак.
Да и все ли обязательно смотрит сразу на сигнатуру. Та же сортировка будет работать заметно тупее.

Это оптимизация.

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

Зачем мы мы упорно прописываем новым файлам расширения?

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

Причем тут development?

У меня нет времени на то чтобы подглядывать mime-type файла. Гораздо проще и быстрее прочесть расширение.

Наличие раширений позволяет раскидывать файлы с помощью однострочников.

Как ты будешь работать с файлами из mc? Файловый менеджер показывает значок, а mc нет. А в файловом менеджере как отличишь фото от видео, если и там и там вместо значка - предпросмотр?

«придется картинки сложить в картинки, видео в видео и тп. И все равно оно постепенно все перепутается, засрется и будет полный бардак.»

ну вообще-то узнавать тип файла по расширению быстрее, чем с помощью утилиты file.

Но расширение ведь не обязано соответствовать, файл jpg а там png и наоборот сплошь и рядом встречается.

2014 год скоро, а люди все так же вручную таскают файлы туда-сюда, а некоторые даже делают это мышкой. ПК давно не средство автоматизации, а уютный втртуальный мир. теперь человек помогает компьютеру выполнять компьютерные задачи. о каком отмирании расширений тут можно говорить

Некоторые flv играются как mp4, если расширение убрать.

find . -type f -name '*.pl' vs libmagic (file utility)

/thread

Слой совместимости с устаревшими ОС?

Ага, с Windows.

есть такая сущность как расширения файлов

4.2.

Магия?

mime, дружочек.

Слой совместимости с устаревшими ОС?

Ты про суффиксы файлов? Не, это нужно пользователю. Но, например, можно было бы не суффиксы, а префиксы делать. Тогда удобно было бы сортировать по типу файлов.

bash-integration в IntelliJ IDEA видит только скрипты с расширением .sh, так что пока нужно :-(

Тогда удобно было бы сортировать по типу файлов.

любой FM и так это делает по суффиксам

shit, а и правда. Просто я так ни разу не делал, не обращал поэтому внимания.

Но таки при замене суффиксов на префиксы получим очевидное преимущество: обычный ls будет сортировать файлы по типам.

тред полон консолезадротов, лол

между тем, нормальные ФМ умеют отображать соответствующую миме-типу иконку, так что да, расширения не нужны

специально удаляю скриптом расширения, и когда знакомые вендузятники просят поделиться кинцом или музычкой, а потом звонят, недоумевая, почему ничего не проигрывается, я глумливо хихикаю в трубку

красавчег)

Очередная протечка тупняка на моём лоре, все в таз

что это делает в девелопмент?

нет никаких расширений, есть имена файлов с точками. file.tar.gz.aes256 это просто имя.

идите познавать мир в толкс

Тупняк. Даже без эксперимента.

Проведите небольшой эксперимент — вручную удалите у ваших -txt -mkv -jpg -avi файликов их расширения и внезапно окажется что не изменилось ровным счётом ничего — всё работает по-старому.

Удалил. Винда спрашивает, каким приложением открывать эту непонятную ерунду.

специально удаляю скриптом расширения, и когда знакомые вендузятники просят поделиться кинцом или музычкой, а потом звонят, недоумевая, почему ничего не проигрывается, я глумливо хихикаю в трубку

пять баллов)

Во-первых, libmagic небесплатен. Весь софт пытается использовать расширение, если оно есть именно потому, что в больших директориях libmagic может угадывать тип за секунды.

Во-вторых, libmagic неидеален. Он ставит приоритет на бинарных файлах. Он затачивается под нужды упоротых на голову сисадминов апача. Он способен опознать юникодный текст как досовый .COM файл (те, кто в курсе, что такое copy of memory, оценят). Вообще, сигнатуры на .com — доказательство того, что у девелоперов libmagic проблемы с головой. Тем временем, люди пилят отдельную эвристику для текстовых файлов т.к. в libmagic мало паттернов.

Нет, в простейших случаях оно работает, но пользоваться эвристикой для всего — ни за что.

Не весь софт под линукс умеет определять тип файла не имеющего расширения (идущий, например, со многими легковесными DE).

Меня шокировало, но OS X тоже не определяет (не работает Quick View и пиктограмму не для всех типов отображает корректно, приложения для открытия выбирает правильно).

Для удобства. Посмотрел на файл и понял, что там должно быть. Если убрать типы файлов то любой каталог превратиться в помойку и нужно будет вспоминать что есть что в ней, каждый раз вызывая file.

Ты про суффиксы файлов?

я считаю это «в имени файла после точки»

Добавь "после последней точки". А то файл можно и так обозвать: this.is.a.very.long.filename.with.some.suffix

Но расширение ведь не обязано соответствовать, файл jpg а там png и наоборот сплошь и рядом встречается.

Кухонными ножами каждый день убивают людей. Но это же не значит, что они предназначены для этого.

Так и с расширениями. Редкие использования не по теме не отменяют общей пользы для быстрой идентификации типа.

вручную удалите у ваших -txt -mkv -jpg -avi файликов их расширения и внезапно окажется что не изменилось ровным счётом ничего — всё работает по-старому. Магия? Да, именно она.

Лучше удали расширение у своих -c -cpp -h файлов, и проверь магию еще раз.

Потом удали с -gz -tgz -srt -deb -rpm -vim и прочее прочее прочее

OSX - тэги?
Похвально, ya-ya-natur

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

о опциональности расширения файлов

Ты прав, но слишком рано остановился. Имена файлов тоже опциональны - по содержимому понятно, что оно такое есть. Аналогично, индексы в БД, без них всё тоже работает.

Но мы и то и другое упорно сопровождаем. Ещё нужно объяснять зачем?

А вот это будет намного забавней, т.к. gcc не умеет парсить содержимое файлов, прежде чем узнать, на каком языке они написаны. И получится весьма прикольно:

file not recognized: Формат файла не распознан
collect2: ошибка: выполнение ld завершилось с кодом возврата 

Но расширение ведь не обязано соответствовать, файл jpg а там png и наоборот сплошь и рядом встречается.

*.avi и *.txt можно обозвать, но это же не норма вещей.

специально удаляю скриптом расширения, и когда знакомые вендузятники просят поделиться кинцом или музычкой, а потом звонят, недоумевая, почему ничего не проигрывается, я глумливо хихикаю в трубку

Ах вот почему линуксоидов всего 1 процент.

Удобнее. Быстрее. Нагляднее.

Да и потому и предложил. Тут недавно тема была где gcc материли

Я бы сказал, расширение - fallback. Если нет информации о mime-type, нет возможности проанализировать заголовок, то остаётся расширение.

Я не ставлю расширения.

На самом деле ничего не мешает сделать (или уже есть?) файловую систему, которая помимо имени файла хранит его тип. Думаю, двух байт хватило бы чтобы закодировать все возможные типы файлов и иметь огромный задел на будущее.

Тонко.

Человек вчера узнал о миме, ну не ломайте же ему кайф!

Я бы сказал, расширение - fallback. Если нет информации о mime-type, нет возможности проанализировать заголовок, то остаётся расширение.

Не совсем — если переименовать jpg в txt то его по даблклику открывает уже kate, а не gwenview.
Или тут накосячили создатели кед?

Ну, кеды используют как раз расширения для определения mime type, судя по настройкам в 'file associations'.

На самом деле ничего не мешает сделать (или уже есть?) файловую систему, которая помимо имени файла хранит его тип.

На самом деле мир не однородный и очень разный. И при перекладывании инфы с такой «умной» фс на всякие флэшки, болванки и прочие интернеты будут происходить всякие несуразности :(

Ну, кеды используют как раз расширения для определения mime type, судя по настройкам в 'file associations'.

Однако если расширения убрать, то текст открывает kate, картинки gwenview, а видео smplayer.
Получается кеды-то всё умеют, но ведутся на расширения и фейлятся с своей такой логикой «доверять имени файла, а не его типу».