продолжать выполнять задание UpStart?

Я ходил с этим кругом. Меня разочаровала переносимость нулевых байтов. Меня не устраивало, что не было надежного способа справиться с ними в скорлупе. Так что я продолжал искать. По правде говоря, я нашел несколько способов сделать это, только пара из которых отмечена в моем другом ответе. Но в результате получились, по крайней мере, две функции оболочки, которые работают следующим образом:

_pidenv ${psrc=$$} ; _zedlmt <$near_any_type_of_file

Сначала я расскажу о разделении \ 0 . На самом деле это довольно легко сделать. Вот функция:

_zedlmt() { od -t x1 -w1 -v  | sed -n '
    /.* \(..\)$/s//\1/
    /00/!{H;b};s///
    x;s/\n/\\x/gp;x;h'
}

Обычно od принимает stdin и записывает в свой stdout каждый полученный байт в шестнадцатеричном формате, по одному на строку.

printf 'This\0is\0a\0lot\0\of\0\nulls.' |
    od -t x1 -w1 -v
    #output
0000000 54
0000001 68
0000002 69
0000003 73
0000004 00
0000005 69
0000006 73
    #and so on

Готов поспорить, вы можете догадаться, что такое \ 0null , верно? Написанный таким образом, легко справиться с any sed . sed просто сохраняет последние два символа в каждой строке до тех пор, пока не встретит нуль, после чего он заменяет промежуточные символы новой строки на удобный формат printf и печатает строку. В результате получается массив шестнадцатеричных байтовых строк с разделителями \ 0null . Посмотрите:

printf %b\\n $(printf 'Fewer\0nulls\0here\0.' |
    _zedlmt | tee /dev/stderr)
    #output
\x46\x65\x77\x65\x72
\x6e\x75\x6c\x6c\x73
\x68\x65\x72\x65
\x2e
Fewer
nulls
here
.

Я передал вышеуказанное в tee , чтобы вы могли видеть как вывод команды susbstitution, так и результат обработки printf . Надеюсь, вы заметите, что подоболочка на самом деле тоже не цитируется, но printf по-прежнему разделяется только по разделителю \ 0null . Смотрите:

printf %b\\n $(printf \
        "Fe\n\"w\"er\0'nu\t'll\\'s\0h    ere\0." |
_zedlmt | tee /dev/stderr)
    #output
\x46\x65\x0a\x22\x77\x22\x65\x72
\x27\x6e\x75\x09\x27\x6c\x6c\x27\x73
\x68\x20\x20\x20\x20\x65\x72\x65
\x2e
Fe
"w"er
'nu     'll's
h    ere
.

Никаких цитат по этому расширению - неважно, цитируете вы его или нет.Это связано с тем, что значения битов проходят без разделения, за исключением одной \ n строки ewline, генерируемой каждый раз, когда sed печатает строку. Разделение слов не применяется. И это то, что делает это возможным:

_pidenv() { ps -p $1 >/dev/null 2>&1 &&
        [ -z "${1#"$psrc"}" ] && . /dev/fd/3 ||
        cat <&3 ; unset psrc pcat
} 3<<STATE
        $( [ -z "${1#${pcat=$psrc}}" ] &&
        pcat='$(printf %%b "%s")' || pcat="%b"
        xeq="$(printf '\\x%x' "'=")"
        for x in $( _zedlmt </proc/$1/environ ) ; do
        printf "%b=$pcat\n" "${x%%"$xeq"*}" "${x#*"$xeq"}"
        done)
#END
STATE

Вышеупомянутая функция использует _zedlmt либо для $ {pcat} подготовленного потока байтового кода для поиска среды любого процесса, который можно найти в / proc , или напрямую .dot $ {psrc} то же самое в текущей оболочке или без параметра, чтобы отображать обработанный вывод того же самого на терминале, например установить или printenv будет. Все, что вам нужно, это $ pid - любой читаемый / proc / $ pid / окружающий файл.

Вы используете это так:

#output like printenv for any running process
_pidenv $pid 

#save human friendly env file
_pidenv $pid >/preparsed/env/file 

#save unparsed file for sourcing at any time
_pidenv ${pcat=$pid} >/sourcable/env.save 

#.dot source any pid's $env from any file stream    
_pidenv ${pcat=$pid} | sh -c '. /dev/stdin'

#feed any pid's env in on a heredoc filedescriptor
su -c '. /dev/fd/4' 4<<ENV
    $( _pidenv ${pcat=$pid} )
ENV

#.dot sources any $pid's $env in the current shell
_pidenv ${psrc=$pid} 

Но в чем разница между дружественным к человеку и источником ? Что ж, разница в том, что отличает этот ответ от всех остальных, включая мой второй. Каждый другой ответ так или иначе зависит от цитирования оболочки для обработки всех крайних случаев. Это просто не так хорошо работает. Пожалуйста, поверьте мне - Я ПЫТАЛСЯ. Посмотрите:

_pidenv ${pcat=$$}
    #output
LC_COLLATE=$(printf %b "\x43")
GREP_COLOR=$(printf %b "\x33\x37\x3b\x34\x35")
GREP_OPTIONS=$(printf %b "\x2d\x2d\x63\x6f\x6c\x6f\x72\x3d\x61\x75\x74\x6f")
LESS_TERMCAP_mb=$(printf %b "\x1b\x5b\x30\x31\x3b\x33\x31\x6d")
LESS_TERMCAP_md=$(printf %b "\x1b\x5b\x30\x31\x3b\x33\x31\x6d")
LESS_TERMCAP_me=$(printf %b "\x1b\x5b\x30\x6d")
LESS_TERMCAP_se=$(printf %b "\x1b\x5b\x30\x6d")
LESS_TERMCAP_so=$(printf %b "\x1b\x5b\x30\x30\x3b\x34\x37\x3b\x33\x30\x6d")
LESS_TERMCAP_ue=$(printf %b "\x1b\x5b\x30\x6d")

НЕТ количество напуганных символов или содержащихся в них кавычек может нарушить это, потому что байты для каждого значения не оцениваются до самого момента, когда контент будет получен. И мы уже знаем, что он работал как значение по крайней мере один раз - здесь нет необходимости в синтаксическом анализе или защите кавычек, потому что это побайтовая копия исходного значения.

Функция сначала оценивает имена $ var и ожидает завершения проверок, прежде чем .dot источник here-doc отправит его в файловый дескриптор 3. Перед тем, как получить его, это На что это похоже. Это надежно. И POSIX портативный. Ну, по крайней мере, обработка \ 0null является переносимой в POSIX - файловая система / process, очевидно, специфична для Linux. И поэтому есть две функции.