в версии 1.3 можно будет точно грабить корованы )

--lzma кстати достаточно нужный и удобный ключик, --lzop тоже вполне пригодный, для бэкапов большого обьема, когда максимум сжатия не нужен

$ tar --version
tar (GNU tar) 1.21
давно уже обновила) как на distrowatch'e вышло

.docx и .xlsx понимает? Не? На помойко!

>.docx и .xlsx понимает

Понимает, с самой первой версии)

Тоись, найдет какой-нить .ODT или .DOCX, распакует из zip, и пережмет в lzma? Ойневерую :)

>распакует из zip

а запаковывать кто будет?

Ну конечно же tar 1.21! :) Он же ж "Понимает, с самой первой версии)", не так ли? ;)

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

>>.docx и .xlsx понимает

>Понимает, с самой первой версии)

Тут наверное дело в том, что не проявится ли излишняя интеллектуальность архиватора, мол архиватор будет распознавать тип файла/архива по его содержимому (.odt - это по сути архив), а не по его расширению. И вместо, скажем сжатия .odt произведет его распаковку.

Такое возможно в оффтопике или в продвинутых мышиных MIME десктопах типа KDE/GNOME. А для CLI все команды указываются в явном виде, т.е. распаковка/запаковка любого файла под полным контролем юзверя еще с нулевой :) версии тара.

Все вышенаписанное, имхо, разумеется.

>.docx и .xlsx понимает

Вдогонку по старинной лоровской традиции: .docx [.xlsx] - фтопку.

И шо? Таки-документооборот у Вас (или в вашей конторе) организован исключительно на ODT/ODS, или на так же фтопочном PDF?

> И шо? Таки-документооборот у Вас (или в вашей конторе) организован исключительно на ODT/ODS, или на так же фтопочном PDF?

Еще используем LaTeX :) и кучу проприетарного физико-математического софта для расчета моделей сферических коней в условиях вакуума.

А для документооборота используются внутренние кошерные софтины - "АИС-*", на чем писанные - не знаю, ибо это уже не моя сфера ответственности.

Между прочим, если собрать Тар без lzma в системе, будет ли он иметь ключ --lzma после установки lzma в системе?

tar всего лишь фронтэнд, он не требует наличия bzip2 gzip lzma и т п для сборки, ключ будет, вот только при его использовании получите что Command not found

:~/tmp$ PATH=/bin tar -cvvJf tar-1.21.tar.lzma tar-1.21/
tar (child): lzma: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now

Все, понял в чем дело.

У меня еще 1.16 стоит, опция в 1.20 появилась :)

s/1.16/1.16.1/

anonymous> И шо? Таки-документооборот у Вас (или в вашей конторе) организован исключительно на ODT/ODS, или на так же фтопочном PDF?

С какой стати PDF "фтопочный"? Формат открытый, польза от него огромная в виде документов, которые требуется распечатать независимо от платформы в одном и том же виде.

А вам не кажется, что иметь несколько страниц опций для программы, которая просто должна собрать много файлов в одну кучу - это неправильно? ИМХО unix-way - это когда каждая программа хорошо делает своё маленькое дело, а для большого дела их используют вместе. Чем использование tar'а с ключами --lzma и --lzop лучше соответствующих конвееров?

tar -cvv DIR | lzma > file.tar.lzma
tar -cvvJf file.tar.lzma DIR

удобнее и короче, это тоже Unix way ) нравится делать pipe - делайте, тем более что можно задавать параметры компрессии например bzip -9 , gzip -9 или lzma -1

а про распаковку с автоопределением типа вообще не говорю )

tar -xf <file>

распакует хоть .tar.gz , хоть tar.bz2 , tar.lzma , tar.lzop )

Опопсел GNU tar.

Сжатие надо указывать компрессору, а не архиватору.
Файлы определенных типов удел find, а не tar.
И еще кучка мелки но раздражающих вещей.

> а про распаковку с автоопределением типа вообще не говорю )

На мой взгляд, эту функциональность надо было помещать не в tar, а в отдельную программу. Своеобразный менеджер архивов для командной строки. Удобство было бы тем же, а возможностей можно было бы реализовать намного больше. Распаковало бы хоть .tar.rar, хоть .tar.lzip.vdm (в смысле vdm_fec). И запаковало бы с шифровкой, и ещё много чего бы сделало. При этом оставляя man tar'а пригодным для чтения :-)

Тролли офигели > Сжатие надо указывать компрессору, а не архиватору. Да пожалуйста, как будто не дает кто-то. > Файлы определенных типов удел find, а не tar. Аналогично. Кстати, что-то я не в курсе, чтобы tar принимал названия файлов, подлежащих помещению в контейнер из pipe (через файл не труъ - это не Unix-way). Да всякие --exclude* будут быстрее работать напрямую через tar, а не find -not -name .... | tar .. > На мой взгляд, эту функциональность надо было помещать не в tar, а в отдельную программу. Возьми, да сделай, кто не даёт-то?

Тролли офигели
> Сжатие надо указывать компрессору, а не архиватору.
Да пожалуйста, как будто не дает кто-то.
> Файлы определенных типов удел find, а не tar.
Аналогично. Кстати, что-то я не в курсе, чтобы tar принимал названия файлов, подлежащих помещению в контейнер из pipe (через файл не труъ - это не Unix-way). Да всякие --exclude* будут быстрее работать напрямую через tar, а не find -not -name .... | tar ..
> На мой взгляд, эту функциональность надо было помещать не в tar, а в отдельную программу.
Возьми, да сделай, кто не даёт-то?
P.S. Блджад, форматирование...

>Опопсел GNU tar

А вам, юзер винрара, какая разница?

Нпонял

Если он - лишь "оболочка", которая сама ничего не делает и ничего не умеет, то зачем об этом целую новость городить было?

>Тролли офигели

Кто тролль ты тролль блджад

>Аналогично. Кстати, что-то я не в курсе, чтобы tar принимал названия файлов, подлежащих помещению в контейнер из pipe

man xargs

Это не только оболочка к компрессорам, но и архиватор.

>Опопсел GNU tar

GNU вообще попсеет семимильными шагами, начиная с неправильного понимания правила модульности unix-way до полного ухода от него (not unix же).

Прекрасно. Ждём ебилдов.

терпеть не могу когда tar еще сжимают, чем zip не угодил?

>GNU вообще попсеет семимильными шагами, начиная с неправильного понимания правила модульности unix-way до полного ухода от него (not unix же).

А чём заключается "уход", позвольте полюбопытствовать?

> терпеть не могу когда tar еще сжимают, чем zip не угодил?

Это unix-way. Каждая программа занимается своим небольшим делом и старается делать это хорошо. Комбинирование программ обеспечивает значительную гибкость.

tar + lzop - наверняка быстрее zip'а.
tar + lzma - наверняка плотнее zip'а.
tar + bzip2 + vdm_fec - с информацией для восстановления. Такое есть у zip'а?

Справедливости ради стоит сказать, что tar + сжималка = непрерывный архив со всеми плюсами и минусами, а иногда удобнее прерывный.
sergey_feo * (*) (28.12.2008 20:29:17)

>Это unix-way. Каждая программа занимается своим небольшим делом и старается делать это хорошо. Комбинирование программ обеспечивает значительную гибкость.

как вытащить _один_ файл из tar.{gz,bz2,lzma,7z} и пр. не распаковывая _весь_ архив? tar был сделан изначально для одной определенной функции - заталкивать файлы на tape, зачем его повсюду пихать-то?

Олололо, вот как раз тролль тут ты. Ты не слышал про ограничение количества параметров, передаваемых проге/скрипту? Не знаю как у тебя (да и знать не хочу), а у меня больше, чем 2^15-1 файлов на диске, причем намного больше. Твой xargs не подавится ли? Да и как быстро сие работать будет? Так, что RTFM. P.S. Кстати, я еще не учитывал, что есть ограничение на _длину_ строки в байтах в целом. Think again.

может потому, что tar сохраняет инфу о владельце и его права на файлы, в отличии от zip-а ? :)

В следующей версии тара обещают ключ --vzhop, позволяющий использовать данные /dev/random как закрытый ключ для шифрования файла.

>как вытащить _один_ файл из tar.{gz,bz2,lzma,7z} и пр. не распаковывая _весь_ архив

это гигантский минус. особенно когда архивы по много гигов.

;)
это идея, надо запатентовать

>> А вам не кажется, что иметь несколько страниц опций для программы, которая просто должна собрать много файлов в одну кучу - это неправильно? ИМХО unix-way - это когда каждая программа хорошо делает своё маленькое дело, а для большого дела их используют вместе. Чем использование tar'а с ключами --lzma и --lzop лучше соответствующих конвееров?

Ну нужно кидаться в крайности и пихать везде этот т.н. "юникс-вей". Очень часто вещи от него становится только хуже и неюзабельней.

Похоже что растет достойная замена emacs'у. Ставлю на то что в tar 2.0 включат elips или что-то аналогичное.

>может потому, что tar сохраняет инфу о владельце и его права на файлы, в отличии от zip-а ? :)

блажен кто верует... посмотрите опцию -X у unzip

>архиватора tar.

олололо

> Похоже что растет достойная замена emacs'у.

+1

Ждём wintar

верной дорогой идем к OS tar

chmod любой архиватор сохраняет. tar же не теряет и более тонкие материи

Объясните убогому, почему tar упорно не хочет с STDIN список файлов для добавления в архив получать?
Конструкция find | xargs имеет ограничение на количество файлов.

Мдяяяяяя....

Попсеет отнюдь не GNU, но LOR. Разницу между фильтрацией через упаковщик и пайпов использованием просеките наконец, юные падаваны! Особенно те, кто хотел не solid.

> .docx и .xlsx понимает? Не? На помойко!

Ананимные дебилы в чате! Закройте тред!