Вопросы Теги

Мишень> (процесс) усекает свой stdout при записи файла

Если Вы ищете строго офлайновую защиту, то что-то как автосмонтированный зашифрованный раздел должно добиться цели. Я вижу, что Вы используете apt-get, таким образом, существует справедливый шанс, Вы находитесь на Ubuntu. В этом случае это могло бы заинтересовать Вас, чтобы знать, что Ubuntu имеет шифрование как опцию во время установки. При использовании Debian вот статья, я нашел, что покрытия, Как настроить зашифрованную файловую систему на нескольких легких шагах.

3
07.04.2013, 12:27
2 ответа

Это были 10 часов, с тех пор как я задал вопрос, и я разработал решение... Примечание: Поскольку я ранее упомянул в комментарии (под вопросом), wait не работает с этими процессами. Я предполагаю, что это вызвано тем, что эти 'замены процесса' не являются 'дочерними' процессами, которым я верю, что wait ожидает. (Я попробовал wait без args)....

Комментарии к его функциям и сбоям ценились бы. Я не вполне понимаю, как stdin взят zenity и tr когда echo первая команда, но я просто думал, что дам ей движение... Это, кажется, работает (в этом случае), но действительно ли этот метод надежен?

Довольно вероятно, будут некоторые хорошо проверенные на практике методы там для занятия этим, таким образом, другие ответы были бы worthwile....

#!/bin/bash
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
# Set up flag-files for processes to send PIDs to main process
# The first thing each process does is: echo -n "$BASHPID " > flag-file  
for i in {1..2};do cp /dev/null "$listf".pid$i;done
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
eval locate $zenargs |tee \
    >(echo -n "$BASHPID " > "$listf".pid1 ; \
      zenity --progress --pulsate --auto-close) \
    >(echo -n "$BASHPID " > "$listf".pid2 ; \
      tr $'\x60' $X01 \
       |sed -n "s/^\(.*\/\)\(.*\)/\1\2\n\2\n\1/p" \
          |while IFS= read -r line ; do \
              #
              #
              # process the data 
              #
              #
          done > "$listf" ) \
    >/dev/null
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
####  WAIT for processes to terminate  
pids=$(cat "$listf".pid{1,2})
while [[ "$pids" == *[0-9]* ]] ; do
   sleep .1 # GNU
   for pid in $pids ; do
      if ! kill -0 "$pid" 2>/dev/null; then
         pids="${pids/$pid/}"
      fi
   done 
done
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
cat "$listf"
#
2
27.01.2020, 21:24
  • 1
    'ожидание' только для фоновых процессов, запущенных с '&' в конце строки (по крайней мере, в ksh, я ожидал бы, что удар является тем же). Вы могли бы получить лучшую пару глаз на этом, если Вы добавляете свою оболочку как тег. Интересная проблема, благодарит совместно использовать ;-)... Удачи! –  shellter 05.04.2011, 22:29
  • 2
    Делает Вы знаете о { print ${Hdr} ; cat ${file} ; } > outFile создайте использование { ; } пары? (точка с запятой как последний маркер перед закрывающей фигурной скобкой очень важна во встроенных конструкциях). Они могут быть довольно сложными, с условной логикой в решении в конечном счете отправляется в > outFile. Я надеюсь, что это помогает. (Извините, но у меня нет времени, чтобы попытаться выяснить точно, что делает Ваш сценарий, я ничего не знаю о zenity). Также отметьте то, что ОС Вы используете? –  shellter 05.04.2011, 22:35
  • 3
    @shellter:Спасибо. я не знал о потребности в финале ;. В контексте моего вопроса, Вашего { } пример, дал реальное понимание как ( ) процесс фона/замены и { } встройте работу процессов в отношении std-I/O. Кажется, что они должны открыть канал FIFO, который доступен любой команде где угодно в блоке процесса. Если я имею верное представление, это действительно довольно просто. tee должен открытие FIFO для каждого процесса. Эти процессы могут быть быстрыми или медленными, и в моем случае, tr процесс был медленнее, чем встроенное stdout канал, таким образом, cat только получил часть файла. ре –  Peter.O 06.04.2011, 09:55
  • 4
    . улучшения цикла ожидания (выше):... если нет никакого собственного компонента bash способ обработать сценарий 'ожидания', затем я полагаю этому кроме некоторого другого способа проверить на рабочий процесс (а не kill -0), затем единственные вещи, в которых это нуждается.. 1) тестирование кодов выхода каждого подпроцесса.. 2) проверка, что файлы флага на самом деле существуют перед продолжением. –  Peter.O 06.04.2011, 09:59

Начиная с версии coreutils 8.24, есть другой способ:

tee -p ( голова -c10M | wc -c)>> (голова -c1 | wc -c) | numfmt --to = iec

Результатом будет

1

10M

Ключевые моменты здесь:

  1. Используйте -p , что вызовет tee предупреждать об ошибках при записи в любой выход, а не в канал. Это означает, что ошибка EPIPE на fwrite не приведет к завершению работы tee , а tee будет работать, пока есть хотя бы один выходной файл, открытый для записи. Если вы хотите получить предупреждение о выводе EPIPE в stderr, используйте - output-error = warn вместо -p .

  2. Используйте >> (head -c1 | wc -c) , чтобы перенаправить стандартный вывод tee на другой > (подстановка процесса) . Это важно по двум причинам. Вам нужно позаботиться о выводе stdout, производимом tee . Если вы используете > / dev / null , например, tee будет работать, пока stdin имеет данные (в данном случае навсегда). В то же время это позволит отправить вывод > (подстановка процесса) на стандартный вывод для дальнейшей обработки. Другие возможности, но не столь элегантные, - это закрыть вывод stdout tee другими способами. Две возможности: > / dev / full и > & - . Однако они будут выдавать предупреждения (tee: стандартный вывод: на устройстве не осталось места и tee: стандартный вывод: неверный дескриптор файла соответственно)

1
27.01.2020, 21:24

Теги

Похожие вопросы