No Ubuntu 18.04, tenho o seguinte comportamento de date:
$ date --version | head -n1
date (GNU coreutils) 8.28
$ date
Вт окт 8 13:18:18 MSK 2019
$ TZ=UTC date
Вт окт 8 10:18:23 UTC 2019
Até agora tudo bem. Mas agora estou tentando fazer o mesmo no Raspbian 9:
$ date --version | head -n1
date (GNU coreutils) 8.26
$ date
Tue Oct 8 13:18:50 MSK 2019
$ TZ=UTC date
Tue Oct 8 13:18:51 MSK 2019
Qual poderia ser o motivo da versão Raspbian de dateignorar a TZvariável de ambiente?
Eu tenho um diretório com mais de 400 GiB de dados nele. Eu queria verificar se todos os arquivos podem ser lidos sem erros, então uma maneira simples que pensei foi tarem /dev/null. Mas, em vez disso, vejo o seguinte comportamento:
$ time tar cf /dev/null .
real 0m4.387s
user 0m3.462s
sys 0m0.185s
$ time tar cf - . > /dev/null
real 0m3.130s
user 0m3.091s
sys 0m0.035s
$ time tar cf - . | cat > /dev/null
^C
real 10m32.985s
user 0m1.942s
sys 0m33.764s
O terceiro comando acima foi parado à força por Ctrl+ Cdepois de já ter sido executado por um bom tempo. Além disso, enquanto os dois primeiros comandos estavam funcionando, o indicador de atividade do dispositivo de armazenamento que continha .estava quase sempre ocioso. Com o terceiro comando, o indicador fica constantemente aceso, o que significa extrema ocupação.
Então, parece que, quando taré capaz de descobrir que seu arquivo de saída é /dev/null, ou seja, quando /dev/nullé aberto diretamente para ter o identificador de arquivo no qual tarescreve, o corpo do arquivo aparece ignorado. (Adicionar vopção para tarimprimir todos os arquivos no diretório sendo tar'vermelho.)
Então eu me pergunto, por que isso é assim? É algum tipo de otimização? Se sim, então por que iria tarquerer fazer uma otimização tão duvidosa para um caso tão especial?
Estou usando o GNU tar 1.26 com glibc 2.27 no Linux 4.14.105 amd64.
No exemplo a seguir, grepse comporta de maneira estranha: é fornecido com a -Iopção, que, de acordo com a página man, deve fazer grepignorar arquivos binários (semelhante a --binary-files=without-match), mas ainda recebo a saída "Correspondências de arquivos binários".
$ cat <<'EOF' | uudecode > test-file
begin 664 /dev/stdout
M>`&5SLU*Q$`0!&#/>8J^"TM/=^8/1%2\>1`\>.^9Z=D-9!))9@7?WBB^@%"G
MHOBHO+8V=2!'-WU3A9PX%*8PBB:VGK@6)Y*HFAB(.2;.;$SQPX=LNG3(>2SH
MDJE!5;R+E9P21J::8U2+?@R>RK&7:[^L&[Q=]UD6>)$D?9<O_82[Y$\&S4_,
MP[G)-)_RVN[!6(S.>F0/M\B(P]$>5[O^%_$8+/(?,CSI+]%DD;/"^^,K3`OD
,6?8=GK6MPS?WDU!"
`
end
EOF
$ grep -I 8 test-file
Binary file test-file matches
$ grep --binary-files=without-match 8 test-file
Binary file test-file matches
Aparentemente, grepconsidera o arquivo binário, mas ainda tenta corresponder e relata os resultados com ele. Por que o "arquivo binário" não é ignorado conforme a -Iopção prescreve?
Estou usando o GNU grep 3.1 no Ubuntu 18.04.
Suponha que eu tenha um aplicativo X, que pega teclado e mouse como seu modo normal de operação (por exemplo, QEMU), mas que, devido a um bug em algum lugar, trava muito (por exemplo, fica preso no modo de suspensão do disco). Normalmente, eu mataria um aplicativo usando kill(1)um terminal remoto, mas se o aplicativo estiver no modo de suspensão do disco, ele não pode ser realmente morto. Eu poderia matar a conexão deste aplicativo com o servidor X pelo xkillutilitário, mas desta vez não posso fazer isso porque o mouse está preso, então xkillnão será executado.
Então, como eu libero meu teclado e mouse da garra de um cliente X, se estou disposto a sacrificar esse cliente, mas não consigo matá-lo pelos meios do sistema operacional?
Eu li em outra resposta que no Android os subinários evitam a necessidade de setuidusar recursos do sistema de arquivos como cap_setuid. Mas então tentei verificar isso e, para minha surpresa, não encontrei recursos definidos no meu sistema Android 8.0 habilitado para Magisk.
Veja como verifiquei:
scp'ed os seguintes
binários retirados dos pacotes Debian arm64 e libcap2:libcap2-binlibc6getcaplibc.so.6libcap.so.2.25libcap.so.2ld-2.27.so
$ su
# whoami
root
# exit
$ type su
su is /sbin/su
$ ls -lh /sbin/su
lrwxrwxrwx 1 root root 12 2018-08-12 22:40 /sbin/su -> /sbin/magisk
$ ls -lh /sbin/magisk
-rwxr-xr-x 1 root root 94 2018-08-12 22:40 /sbin/magisk
$ sed 's@^@> @' /sbin/magisk
> #!/system/bin/sh
> unset LD_LIBRARY_PATH
> unset LD_PRELOAD
> exec /sbin/magisk.bin "${0##*/}" "$@"
$ ls -lh /sbin/magisk.bin
-rwxr-xr-x 1 root root 71K 2018-08-12 22:40 /sbin/magisk.bin
$ file /sbin/magisk.bin
/sbin/magisk.bin: ELF shared object, 32-bit LSB arm, dynamic (/system/bin/linker), stripped
$ LD_LIBRARY_PATH=. ./ld-2.27.so ./getcap -v /sbin/magisk.bin
/sbin/magisk.bin
Como você pode ver, nem setuido bit nem nenhum recurso está presente no /sbin/magisk.binbinário. Então o que está acontecendo? Como funciona?
Tenho um gerador de arquivos rodando, onde cada arquivo tem um nome alfabeticamente seguindo o anterior. No começo eu estava fazendo meu loop como for file in /path/to/files*; do..., mas logo percebi que o glob só se expandiria antes do loop, e quaisquer novos arquivos criados durante o loop não seriam processados.
Minha maneira atual de fazer isso é bem feia:
while :; do
doneFileCount=$(wc -l < /tmp/results.csv)
i=0
for file in *; do
if [[ $((doneFileCount>i)) = 1 ]]; then
i=$((i+1))
continue
else
process-file "$file" # prints single line to stdout
i=$((i+1))
fi
done | tee -a /tmp/results.csv
done
Existe alguma maneira simples de percorrer uma lista cada vez maior de arquivos, sem o hack descrito acima?