Просто распаковать «простое»

Да никак. Ты же понимаешь, что ты тупо положил вывод этих команд в текстовые файлы. Теперь обрабатывай текстовые файлы. Мы же не знаем, что у тебя там за содержимое, поэтому парсить это тебе самому. Тебе нужно было использовать tar, а не маяться вот этим вот. Тем более, сжатие использовать совсем-совсем не обязательно, и это будет ничуть не медленнее, чем сделал ты, но только вот несколько проще и правильнее.

Мы же не знаем, что у тебя там за содержимое

Здрасте-мордасти. test.ls - описание содержимого. test.cat - само содержимое.

несколько проще и правильнее.

Смотря как посмотреть и для каких целей.

Никак, ведь ты отбросил информацию об именах и длинах файлов.

отбросил информацию об именах и длинах файлов.

test.ls

Ну ты совсем не понимаешь, чтоли? Как из того, что ты себе там «заархивировал» определить, какое содержимое к какому файлу относится? По заголовкам ZIP от txt отличать? А если это DOCX vs XML vs ZIP? Ты сам вот подумай, прежде чем бредить и пытаться изобретать велосипед. Нет, твой подход не верен. Хотя можешь, конечно, пропарсить вывод *.lst, взять имя файла из вывода, размер, откусить кусок файла, сохранить и т.п. Ну в общем cat, grep, cut, awk/sed тебе в помощь, да. Пиши теперь скрипт и пердолься.

какое содержимое к какому файлу относится?

В test.ls содержится и имя, и длина, и даже атрибуты.

Да, сорян, не заметил сразу, а потом не успел удалить коммент до твоего ответа.

Ну смотри, можно распарсить test.ls и вытащить твои файлы обратно. Но: общепризнано, что парсить выхлоп ls - плохая практика, он слишком изменчивый, особенно если есть странные имена файлов. В остальном - да, ты придумал нестандартный аналог tar.

Ну. А теперь сообрази, как работает tar. Точно так же, только всё пишется в один файл: сначала атрибуты и метаданные, потом содержимое файла, потом со следующим так же и т.п. Ты тут вот хочешь странного. Ну бери, парси вывод ls относительно каждого файла и вырезай его часть из «архива».

echo «_______

К чему разделители, если есть полное описание test.ls?

Кстати, а вот это можно будет несколько более простым методом разархивировать, если атрибуты тебе не нужны.

и вырезай его часть из «архива».

А вот здесь поподробнее. Принятые решения?

А то, что порядок в test.ls может не совпадать с порядком «архивации».

А то, что порядок в test.ls может не совпадать с порядком «архивации».

К чорту подробности.

man grep, man cut, man awk, man head, man tail, man sed. Я не знаю, что именно из этого ты будешь использовать, но делать за тебя мне честно лень. Без пердолинга никак, а судя по этому треду, ты хочешь попердолиться, только не в силах это признать.

man grep, man cut, man awk, man head, man tail, man sed

tail + head? Я думал есть что-то более нацеленное.

Ну, а как вообще работают с текстовыми файлами в bash?

идея аналогична самораспаковывающимся шелл-скриптам: https://www.linuxjournal.com/node/1005818

тебе надо получить offset и размер очередного файла. потом tail -n+size и готово. и, да, ты можешь всё слить в один файл: распаковщик, test.ls и test.cat[.gz]

как вообще работают с текстовыми файлами в bash?

Да согласен. Просто слегка недоволен.

потом tail -n+size

Я вообще то через head -c N | tail -c size хотел. А что у Вас за «конструкция»?

у нас? у кого?

по ссылке пройди, там всё разжевано это…

https://www.linuxjournal.com/node/1005818

The parameter

-n+$ARCHIVE

tells tail to start at line number we just read in the previous command, and print til the end of the file.

Не то. Не надо нам никаких строк.

Я думал есть что-то более нацеленное.

конечно, tar

а ты ожидал, я тебе готовое решение принесу? :) нет, этого не произойдет.

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

конечно, tar

Неинтересно.

Ну так читай в цикле test.ls, получай имя файла и размер, читай нужный кусок с помощью dd или tail и все. Делов то.

читай нужный кусок с помощью dd

С помощью dd напомни:

$ dd if=test.cat of=${tfile} bs=1 skip=${presize} count=${size}
$ file ${tfile}

Так?

Ну какой-то такой распаковщик может быть:

exec < ../test.cat
exec {ls}< ../test.ls

while read -r -u $ls perms hardlinks user group size month day time filename; do
  head -c "$size" > "$filename"
  #chown "$user:$group" "$filename" #требует рута
  #TODO: perms mdate
done

Но он, разумеется, сломается на файлах с именами типа

вот
такое
имя

Совершенно верно.

$ cat a
1234567890
$ dd if=a bs=1 skip=3 count=2 status=none
45%                                                                                                                                                                       $ 

Я после поста автора полез экспериментировать, и обнаружил что vim умеет напрямую с tar работать :D

dd

Упаковщик Попова.

Попов, перелогинься.

Всё равно ТС не нужен.

Всё равно ТС не нужен.

Как скажешь.

ados.

Что это?

Ритуал. Не обращай внимания.

Небольшая головоломка

простое

∞!=...

По-моему практичнее сделать что-то вроде multipart/form-data, чтобы сложно не считать смещения. Это сложнее, чем просто выхлоп ls и cat, но проще, чем tar в плане реализации запаковки из подручных средств

практичнее сделать что-то вроде multipart/form-data

Насколько я понял, multipart/form-data более похож на tar и представляет собой последовательность head+data. У этого есть плюсы: можно как и в tar лепить «упаковку» из файлов «кирпичиками». Но есть и минус (как и у tar): нет единого описания (test.ls).