Пара вопросов по tar

cd foo
tar ...

1) cd foo && tar -c bar > ../bar.tar

2) Оптимизировать с какой целью? Чем не устраивает дефолт?

cd foo && tar -c bar > ../bar.tar

Или меньше значков: tar -cf bar.tar -C foo bar

если gnu tar - то, как вариант, man в районе `strip'

--strip-components=n не подходит, т.к. количество компонентов может быть разным когда на архивацию передаётся несколько файлов

2) Оптимизировать с какой целью? Чем не устраивает дефолт?

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

по дефолту нормально и не надо ничего трогать

this

tar - ленточный архиватор, чего ты там оптимизировать собрался? Он тупо (не совсем, если строго к этому подходить) файлы клеит один за другим без всяких сжатий.

dd тоже тупо перекладывает блоки, и тем не менее bs=

У dd без (i/o)bs не обойтись по причине count, skip, seek, которые N*bs. tar-у размер блока нужен был при работе с raw-устройствами, несовпадение приводило к невозможности позиционировать ленту на конец архива и начала следующего. Теперь при практическом изчезновении raw, требовать оптимизации для tar так же бессмысленно, как и для cp.

dd без bs медленно работает.

Нужно создавать так:

tar -czf archive_name.tar.gz -C /path/to/foo/ bar/

после завершения tar вернуться обратно

Сами придумали?

dd без bs медленно работает

Там по умолчанию bs=512, что в 8 раз меньше чем тупо у stdio = для x86 - 4k page_size

Именно.

Именно.

Что лишний раз доказывает, что dd — это пережиток 70-х, disk dupe от CP/M, с унаследованным синтаксисом и способом работы, на данный момент с отходом от raw устройств натуральный анахронизм, обвешенный костылями, но удивительно живуч.

А что неверного я написал? После завершения работы tar, текущий каталог будет тот же, что и был до запуска tar.

А что неверного я написал? После завершения работы tar, текущий каталог будет тот же, что и был до запуска tar.

Вы написали чушь.

1. chdir - это сискол, локальный на процесс, никуда tar не возвращается, он просто тупо завершается оставаясь в том каталоге, что он сделал после -C dir.

2. Пара вопросов по tar (комментарий) — слабо перед тем как писать читать тред?

слабо перед тем как писать читать тред?

Ты написал без пояснения, я написал подробнее.

1. chdir - это сискол, локальный на процесс, никуда tar не возвращается, он просто тупо завершается оставаясь в том каталоге, что он сделал после -C dir.

Итак дано: ubuntu 16.04, tar 1.28

pwd
# вывод:
# /home/rumgot

mkdir -p foo/bar

tar -cf arc.tar -C foo bar

pwd
# вывод:
# /home/rumgot

Так что у меня проверено, а ты болтаешь.

О, Боже. Вам бы книжки почитать, а потом уже советы пытаться давать. А может вас из криокамеры достали, из 69 года? Тогда, действительно, cd делался так, в /bin лежал бинарник cd, он правил в памяти запустившего его процесса его рабочий каталог... Или может у вас tar встроен в вашу командную оболочку? Вы вообще понимаете, что такое процесс и его локальное окружение?

Что-то ты впал в истенику как девочка. Сумбурщина какая-то. Подлечи ка нервишки.

https://xkcd.com/1168/

Он вам пытался скащать, что тар не возвращается. Просто процесс вызывавший тар никуда и не уходил.

Ух уж эти филологи-теоретики-линуксоиды...:-)
По факту: каталог меняется? - меняется. Может при формулировке я выразился не совсем терминологически верно, готов признать, но можно ведь нормально ответить, чего тут плакаться?

Он вам пытался скащать, что тар не возвращается.

Да бесполезно. Забейте.

Небольшой урок тебе на будущее. Сколь много бы ты не знал, это не имеет не малейшего значения, если ты не умеешь внятно объяснить, чего ты хочешь.