передача dd skip|seek смещение как шестнадцатеричное
Ну, от вершины (родитель arndell, claremont, и monte) каталоги Вы могли ввести:
ls */*/{weekly,daily}
Который расширяется до:
ls */*/weekly */*/daily
Который показал бы Вам содержание весь weekly и daily каталоги.
Почему вторая команда производит другое значение?
По историческим причинам, dd рассматривает x быть оператором умножения. Так 0x3 оценен, чтобы быть 0.
Действительно ли возможно передать смещение skip|seek dd как шестнадцатеричное значение?
Не непосредственно, насколько я знаю. А также умножение с помощью оператора x, можно снабдить суффиксом любое число b для значения "умножаются на 512" (0x200) и с K для значения "умножаются на 1 024" (0x400). С GNU dd Вы может также использовать суффиксы M, G, T, P, E, Z и Y для значения умножаются на 2 к питанию 20, 30, 40, 50, 60, 70, 80 или 90, соответственно, и можно использовать верхний регистр или нижний регистр за исключением b суффикс. (Существует много других возможных суффиксов. Например, EB означает, "умножаются на 1 018" и PiB означает, "умножаются на 250". Посмотрите info coreutils "block size" для получения дополнительной информации, если у Вас есть установка GNU.)
Вы могли бы найти вышеупомянутое тайным, анахроничным, и гиковским на грани нелепости. Не волноваться: Вы не являетесь одними. К счастью, можно просто проигнорировать все это и использовать арифметическую замену оболочки вместо этого (удар и другой Posix, совместимые оболочки будут работать, а также некоторые оболочки non-Posix). Оболочка действительно понимает шестнадцатеричные числа, и она позволяет полный спектр арифметических операторов, записанных нормальным способом. Просто необходимо окружить выражение $((...)):
# dd if=2013-Aug-uptime.csv bs=1 count=$((0x2B * 1024)) skip=$((0x37))
Я знаю, что это старая ветка, но проблема по-прежнему актуальна, как никогда, особенно когда такие идиоты, как я, случайно вспоминают и извлекают «cp fileA fileB» из истории bash, когда fileB еще не проверен -в git без резервной копии и содержит несколько часов кодирования после всего -nighter :-/
Благодаря концепциям, изложенным в этой теме, я смог полностью восстановить свой потерянный файл, однако я потерял свой на удаленном виртуальном частном сервере с 32-гигабайтным диском и очень небольшим объемом оперативной памяти (под управлением Ubuntu 18.04 ), и все мои попытки использовать «grep», как указано выше, быстро заканчивались «недостаточно памяти»
В моем случае это был hexdump -C /dev/sdX1 | grep 'shortString', который пришел мне на помощь. В отличие от grep, он отображает только очень узкое ASCII-представление шестнадцатеричного кода, поэтому очень важно искать только короткую уникальную строку и иметь в виду, что даже она может быть обернута. Как только он вывел какой-то шестнадцатеричный адрес, где было совпадение, я смог использовать «дд» аналогично тому, как описано выше, за исключением того, что я обнаружил, что по умолчанию размер блока равен 4096, поэтому мне пришлось не только преобразовать адрес шестнадцатеричных байтов в десятичный, но разделить его на 4096, чтобы масштабировать его до блоков 4 КБ для параметра пропуска -dd, что бесполезно, если это число слишком велико для dd, сообщение об ошибке выглядит так, как будто оно жалуется на то, что skip=недействителен, а не номер перешел к нему.
Престижность людям, которые добавили советы по использованию bash с $((0xabcd))в easilty obtaion hex ->dec конвертация:-)
Только последнее слово. -В моем случае было несколько копий одного и того же файла, и все они находились в непосредственной близости друг от друга. Но, вычитая самый низкий адрес из самого высокого адреса, сообщенного hexdump, я смог идентифицировать ~5-мегабайтную область, содержащую все возможные копии, что означало, что я мог выбрать dd по самому низкому адресу и извлечь всю эту область во временный файл. Редактор Vim теперь довольно изящно обрабатывает двоичный контент, поэтому вы можете затем изучить временный файл и изменить его форму по мере необходимости.
$((...))расширение арифметики POSIX, это не удар, конкретный вообще, Вы не должны использоватьbashдля использования его любая оболочка POSIX сделает. Однако обратите внимание на это во многих оболочках включаяbash, это подвергается слову, разделяющему, так должен быть заключен в кавычки. – Stéphane Chazelas 05.08.2013, 10:08$((...))ничего не изменит. Единственный случай, о котором я могу думать, где кавычки сделали бы что-либо, - то, если у Вас было что-то какIFS=4но это вызвало бы все виды другого хаоса. – rici 06.08.2013, 03:00$((...)). POSIX ясен что расширение$((...))подвергается разделению слова. Отъезд любого из расширений команды/арифметики/переменной, закрывших кавычки в контексте списка, является split+glob оператором. Установка IFS=4 не вызвала бы все виды проблем, если Вы не используете split+glob оператор, где это - не нужный/, требуемый, и установило IFS каждый раз, когда Вам нужно это split+glob оператор. – Stéphane Chazelas 06.08.2013, 21:07IFSк чему-то, что включает цифры, что-то, которое я не полагаю, что когда-либо делал, затем необходимо было бы заключить в кавычки. По-видимому, если бы Вы делали это, то можно было бы знать о потребности, так как это - едва что-то, что, вероятно, сделает небрежно. Или по крайней мере, это - едва что-то, что я, вероятно, сделаю, период. Я не означаю говорить за Вас. – rici 06.08.2013, 21:43