Как узнать, является ли файл тарболом?

file <file>

И дальше смотри вывод.

man file

если тарбол сжатый, то file не выводит что это тарбол. можно как-то определять, что сжатый тарбол, это именно тарбол?

по расширению

не UNIX-way. да и расширений десятки, всякие .tbz, .txz

это именно тарбол?

tar -tf "file"

похоже, только через ключ t

Самый православный метод по содержимому т.е. file -b --mime-type а расширение в этих наших линуксах не значит ровным счётом ничего.

а расширение в этих наших линуксах не значит ровным счётом ничего.

Только много софта уже привязано именно к расширениям.

Много это сколько? Приведи хотя бы десяток мейнстримного софта на линуксе, который привязан к расширению в имени файла.

Только много софта уже привязано именно к расширениям.

Неправда - подавляющему большинству софта в gnu/linux как раз таки на расширения вообще плевать ибо изначально именно таковой была идеология а то что её в процессе засрали это уже предмет другого разговора.

А вот в этих ваших говновендазах там да там хлебом не корми только дай с расширениями файла «поиграть» и плевать что там на самом деле внутри.

считать первый килобайт ентого файла и проверить на наличие заголовков tar.
мысль дальше: если в начале файла найдутся заголовки сжимателей gzip bzip xzip и других которые захочешь поддерживать, то расжать начало файла (1 кб хватит) и поискать в расжатом заголовки tar
но сие не труюниксвей, ибо требует думать и говнокодить.

если тарбол сжатый

то это не тарболл.

мысль дальше: если в начале файла найдутся заголовки сжимателей gzip bzip xzip и других

zip, rar, ha, arj, vic, pak... И обязательно предусмотреть возможность упаковки в несколько архивов последовательно. С паролями.

предусмотреть все упаковщики и архиваторы (надеюсь ты их не путаешь ??) оставим на желание автора. это всего лишь дополнительные строчки кода.

Например, gcc, куда уж более мейнстримный софт, а и тот C от C++ отличает именно по расширению.

если тарбол сжатый

То узнавать тип файла точно так же как и не с тарболлами — разжимая — очевидно же.

предусмотреть все упаковщики и архиваторы (надеюсь ты их не путаешь ??)

Что такое архиватор — знаю (tar, cpio и иже с ними), а что такое упаковщик? Синоним компрессора или что-то другое?

https://ru.wikipedia.org/wiki/Упаковка_исполняемых_файлов

К тарболлам не применимо ;)

Или таки имелись в виду комбайны — архиваторы (это всё же именно они) со встроенной функцией компрессии?

предусмотреть все упаковщики и архиваторы (надеюсь ты их не путаешь ??

Не путаю. Архиватор - программа для упаковки файлов в единый архив. Упаковщик - профессия, востребованная на складе и производстве.

читать первые сколько-то там байт на предмет magic.

gzip умеет выдавать своё содержимое:

 % file -b awesome.gz
gzip compressed data, was "awesome", last modified: Fri Jun  7 13:45:08 2019, from Unix, original size 435

Например, gcc, куда уж более мейнстримный софт, а и тот C от C++ отличает именно по расширению.

gcc может поступать так как ему угодно. А вот IEEE Std 1003.1-2017/POSIX вообще ничего не знает про эти твои „расширения“: Filename, Filename String, Portable Filename, Portable Filename Character Set.

У mc есть ~/.config/mc/mc.ext. Без него не откроешь приложение, связанное с расширением файла. Вроде приложение еще с «тех» времен.

Мне нужно определять, если файл — тарбол, с ним будет работать tar, если нет — atool.

Когда у меня возникла подобная проблема я поступил вот так: 0, 1 и собственно 3.

Да не идеально. Уж совсем по хорошему надо еще сравнивать mime с расширением и посылать далеко если одно не соответствует другому.

У mc есть ~/.config/mc/mc.ext. Без него не откроешь приложение, связанное с расширением файла. Вроде приложение еще с «тех» времен.

Есть. И кроме этого есть ещё сотни софта понабежавшего с вендаза и/или на вендаз и/или написаного левой пяткой вендо-макаки. Однако кроме этого есть, к примеру, bash. И вот он определяет „своих“ по первой строчке #!/usr/bin/env bash и при этом ему главное бит исполнимости а на расширение ему плевать с высокой колокольни.

bash

он определяет „своих“ по первой строчке #!/usr/bin/env bash

Это делает не он.

#! обрабатывается ядром. А башескрипты в уже запущенном баше работают без этой строчки.

Это делает не он.

Уговорил.

А башескрипты в уже запущенном баше работают без этой строчки.

Собственно равно как и без расширений.

угу, компрессора :) высокого давления. мысль была что нет предела совершенству. к примеру файлы представляющие собой многосложную конструкцию в виде архива ar, содержащего несколько xz-сжатых tar-архивчиков с файликами, весьма распространены :)

вот что значит не читать документацию.
у file есть ключ -Z для распаковки. мне это подходит. но, наверное, не будет работать для запароленных сжатых тарболов

Собственно равно как и без расширений.

С расширениями все равно удобней. Можно ассоциировать файлы с приложениями. В чем открыть по умолчанию, в gimp, и gwenview или в okular. Расширения передают информацию о типе файла визуально, что удобно для пользователя.

расширения для идентификации это как «джентельменское соглашние»: не всегда это соблюдается. или не когда не видел файлов с «чужим» расширением? например, качаешь что-то с какого-то сайта — сохраняет тебе *.html (на самом деле там *.pdf или *.zip, или ...) как и наоборот сохранил *.pdf — внутри стандартная страничка в html — «нет файла/нужно авторизоваться/...)