cas's questions

Recentemente, notei que havia links simbólicos extras /dev/disk/by-idpara minhas unidades NVME, com as duplicatas com o mesmo nome _1anexado.

# ls -lF /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW{,_1}
lrwxrwxrwx 1 root root 13 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1 -> ../../nvme0n1

(números de série editados principalmente para XXXXXXXX sem nenhum motivo específico)

e duplica as entradas para todas as partições nas unidades NVME também:

$ ls -lF /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1*-part*'
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part3 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part4 -> ../../nvme0n1p4
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part5 -> ../../nvme0n1p5
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part6 -> ../../nvme0n1p6
lrwxrwxrwx 1 root root 15 Jul 29 19:22 /dev/disk/by-id/nvme-Samsung_SSD_970_EVO_500GB_S466XXXXXXXXXXW_1-part7 -> ../../nvme0n1p7

Isso está acontecendo apenas para minhas unidades NVME, não para minhas unidades flash SATA ou USB.

Não consigo ver nada óbvio nisso /usr/lib/udev/rules.d/60-persistent-storage.rules.

Alguém sabe por que udevestá fazendo isso? E, mais importante, como pará-lo?

Ontem, enquanto escrevia uma resposta para Como obter nomes de caminhos completos de todos os arquivos PDF abertos (em zathura) - como rofi faz , notei algo estranho sobre a propriedade de arquivos no diretório /proc/PID/ para processos zathura - a maioria deles são de propriedade do root em vez do usuário (cas) Eu corri zathura como .

Por exemplo:

$ cd ~/Manuals
$ zathura X399\ Taichi.pdf &
[1] 4055396

$ ls -lF /proc/4055396/fd
ls: cannot open directory '/proc/4055396/fd': Permission denied
$ ls -lFd /proc/4055396/fd
dr-x------ 2 root root 0 Mar 31 13:04 /proc/4055396/fd/

huh? por que isso é propriedade de root? Eu executei como cas.

A maioria, mas não todos os arquivos/diretórios em /proc/4055396 são de propriedade do root:

$ ls -lF /proc/4055396
ls: cannot read symbolic link '/proc/4055396/cwd': Permission denied
ls: cannot read symbolic link '/proc/4055396/root': Permission denied
ls: cannot read symbolic link '/proc/4055396/exe': Permission denied
total 0
-r--r--r--  1 root root 0 Mar 31 13:04 arch_status
dr-xr-xr-x  2 cas  cas  0 Mar 31 13:04 attr/
-rw-r--r--  1 root root 0 Mar 31 13:04 autogroup
-r--------  1 root root 0 Mar 31 13:04 auxv
-r--r--r--  1 root root 0 Mar 31 13:04 cgroup
--w-------  1 root root 0 Mar 31 13:04 clear_refs
-r--r--r--  1 root root 0 Mar 31 13:02 cmdline
-rw-r--r--  1 root root 0 Mar 31 13:04 comm
-rw-r--r--  1 root root 0 Mar 31 13:04 coredump_filter
-r--r--r--  1 root root 0 Mar 31 13:04 cpu_resctrl_groups
-r--r--r--  1 root root 0 Mar 31 13:04 cpuset
lrwxrwxrwx  1 root root 0 Mar 31 13:04 cwd
-r--------  1 root root 0 Mar 31 13:04 environ
lrwxrwxrwx  1 root root 0 Mar 31 13:02 exe
dr-x------  2 root root 0 Mar 31 13:04 fd/
dr-xr-xr-x  2 cas  cas  0 Mar 31 13:04 fdinfo/
-rw-r--r--  1 root root 0 Mar 31 13:04 gid_map
-r--------  1 root root 0 Mar 31 13:04 io
-r--------  1 root root 0 Mar 31 13:04 ksm_merging_pages
-r--------  1 root root 0 Mar 31 13:04 ksm_stat
-r--r--r--  1 root root 0 Mar 31 13:04 limits
-rw-r--r--  1 root root 0 Mar 31 13:04 loginuid
dr-x------  2 root root 0 Mar 31 13:04 map_files/
-r--r--r--  1 root root 0 Mar 31 13:04 maps
-rw-------  1 root root 0 Mar 31 13:04 mem
-r--r--r--  1 root root 0 Mar 31 13:04 mountinfo
-r--r--r--  1 root root 0 Mar 31 13:04 mounts
-r--------  1 root root 0 Mar 31 13:04 mountstats
dr-xr-xr-x 57 cas  cas  0 Mar 31 13:04 net/
dr-x--x--x  2 root root 0 Mar 31 13:04 ns/
-r--r--r--  1 root root 0 Mar 31 13:04 numa_maps
-rw-r--r--  1 root root 0 Mar 31 13:04 oom_adj
-r--r--r--  1 root root 0 Mar 31 13:04 oom_score
-rw-r--r--  1 root root 0 Mar 31 13:04 oom_score_adj
-r--------  1 root root 0 Mar 31 13:04 pagemap
-r--------  1 root root 0 Mar 31 13:04 patch_state
-r--------  1 root root 0 Mar 31 13:04 personality
-rw-r--r--  1 root root 0 Mar 31 13:04 projid_map
lrwxrwxrwx  1 root root 0 Mar 31 13:04 root
-rw-r--r--  1 root root 0 Mar 31 13:04 sched
-r--r--r--  1 root root 0 Mar 31 13:04 schedstat
-r--r--r--  1 root root 0 Mar 31 13:04 sessionid
-rw-r--r--  1 root root 0 Mar 31 13:04 setgroups
-r--r--r--  1 root root 0 Mar 31 13:04 smaps
-r--r--r--  1 root root 0 Mar 31 13:04 smaps_rollup
-r--------  1 root root 0 Mar 31 13:04 stack
-r--r--r--  1 root root 0 Mar 31 13:02 stat
-r--r--r--  1 root root 0 Mar 31 13:04 statm
-r--r--r--  1 root root 0 Mar 31 13:04 status
-r--------  1 root root 0 Mar 31 13:04 syscall
dr-xr-xr-x  6 cas  cas  0 Mar 31 13:04 task/
-rw-r--r--  1 root root 0 Mar 31 13:04 timens_offsets
-r--r--r--  1 root root 0 Mar 31 13:04 timers
-rw-rw-rw-  1 root root 0 Mar 31 13:04 timerslack_ns
-rw-r--r--  1 root root 0 Mar 31 13:04 uid_map
-r--r--r--  1 root root 0 Mar 31 13:04 wchan

zathuraNÃO é raiz setuid:

$ type -p zathura
/usr/bin/zathura

$ ls -l /usr/bin/zathura
-rwxr-xr-x 1 root root 305456 Nov 28 03:34 /usr/bin/zathura

É a versão 0.5.2 e o pacote foi atualizado pela última vez em 28 de novembro do ano passado:

$ zathura --version
zathura 0.5.2
girara 0.3.7 (runtime: 0.4.0)
(plugin) cb (0.1.10) (/usr/lib/x86_64-linux-gnu/zathura/libcb.so)
(plugin) pdf-poppler (0.3.1) (/usr/lib/x86_64-linux-gnu/zathura/libpdf-poppler.so)
(plugin) ps (0.2.7) (/usr/lib/x86_64-linux-gnu/zathura/libps.so)
(plugin) djvu (0.2.9) (/usr/lib/x86_64-linux-gnu/zathura/libdjvu.so)

$ dpkg -l zathura
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=============================================
ii  zathura        0.5.2-1      amd64        document viewer with a minimalistic interface

$ ls -l /var/cache/apt/archives/zathura_0.5.2-1_amd64.deb 
-rw-r--r-- 1 root root 175712 Nov 28 04:41 /var/cache/apt/archives/zathura_0.5.2-1_amd64.deb

Se eu usar qpdfview, atril, ou okularem vez de zathura, as permissões estão corretas:

$ qpdfview X399\ Taichi.pdf 
$ pgrep qpdfview
4071588 qpdfview X399 Taichi.pdf
$ ls -lFd /proc/4071588/fd
dr-x------ 2 cas cas 0 Mar 31 13:16 /proc/4071588/fd/

$ atril X399\ Taichi.pdf &
[1] 4080297
$ ls -lFd /proc/4080297/fd
dr-x------ 2 cas cas 0 Mar 31 13:20 /proc/4080297/fd/

$ okular X399\ Taichi.pdf &
[1] 4081710
$ ls -lFd /proc/4081710/fd
dr-x------ 2 cas cas 0 Mar 31 13:21 /proc/4081710/fd/

Todos os itens acima foram executados na mesma instância do bash, mesmo ambiente, tudo igual. Não em uma VM ou contêiner, ou qualquer coisa "incomum".

Então, o que está acontecendo zathura? É zathura? ou é algum comportamento estranho relacionado a namespaces por systemd ou cgroups ou algo assim?

O sistema está rodando Debian sid (atualizado ontem), com kernel Linux hex 6.1.0-6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05) x86_64 GNU/Linux. A última reinicialização foi há 14 dias, quando atualizei o kernel, e está funcionando bem desde então.

NOTA: Lembro-me vagamente de que, quando estava trabalhando em minha resposta ontem, vi a mesma coisa de propriedade raiz para UMA das instâncias de running atril, mas não posso replicar isso agora. Posso ter me lembrado mal disso, era muito tarde da noite (> 3 da manhã) e eu estava cansado.

zathura, no entanto, consistentemente tem coisas de propriedade do root em /proc/PID/ - toda vez que eu o executo.

Eu tenho várias centenas de arquivos .xhtml em um subdiretório(*) e quero excluir todos os DIVs com uma classe específica (e todo o conteúdo desses DIVs - incluindo outros divs, spans, elementos de imagem e parágrafo) deles. O DIV pode aparecer zero, uma ou mais vezes em qualquer profundidade arbitrária dentro de cada arquivo .xhtml.

Os DIVs específicos que quero excluir são:

<div class="portlet solid author-note-portlet">.....</div>

Usando o xml_greputilitário do módulo perl XML::Twig , posso executar xml_grep -v 'div[@class="portlet solid author-note-portlet"]' file*.xhtmle ele removerá todas as instâncias dessa div dos arquivos .xhtml e exibirá o resultado em stdout. Exatamente o que eu quero, exceto por "exibir no stdout".

Se xml_greptivesse algum tipo de opção de edição no local, tudo bem, eu apenas usaria isso .... mas não, então eu teria que escrever um script wrapper que usasse um arquivo temporário ou spongee executar xml_grep em cada arquivo .xhtml individualmente, o que seria lento e tedioso. Ou eu poderia hackear uma cópia do xml_grep para que ele pudesse editar seu(s) arquivo(s) de entrada.

Mas não quero fazer nenhuma dessas coisas, quero usar a ferramenta existente que já pode fazer isso, quero usar xmlstarlet- será mais rápido, tem edição no local e não precisarei execute-o uma vez por nome de arquivo.

O problema é que não importa o que eu tente (e já tentei dezenas de variações), não consigo descobrir a especificação xpath correta para excluir um div com essa classe. por exemplo, eu tentei:

xmlstarlet ed -d "div[@class='portlet solid author-note-portlet']" file.xhtml

e (com cotação diferente)

xmlstarlet ed -d 'div[@class="portlet solid author-note-portlet"]' file.xhtml

e

xmlstarlet ed -d '//html/body/div/div/div[@class="portlet solid author-note-portlet"]'

e dezenas de outras variações. Nenhum deles resultou em qualquer alteração na saída xhtml. Este é o ponto em que eu costumo desistir de xmlstarlet e escrever um script perl, mas desta vez estou determinado a fazê-lo com xmlstarlet.

Então, qual é a maneira correta de especificar essa classe div para xmlstarlet?

BTW, para um exemplo de arquivo .xhtml (com duas instâncias deste div, que estão na mesma profundidade ... o que é bastante típico, mas não universal), xmlstarlet el -vdiz:

$ xmlstarlet el -v OEBPS/file0007.xhtml | grep author-note-portlet
html/body/div/div[@class='portlet solid author-note-portlet']
html/body/div/div[@class='portlet solid author-note-portlet']

(*) Não que isso importe, mas esses arquivos .xhtml estão dentro de um arquivo .epub(**) gerado pelo plugin FanFicFare para Caliber - que baixa todos os capítulos de livros em vários sites de ficção e os transforma em um arquivo epub ( que é basicamente um arquivo zip contendo arquivos XHTML e CSS e talvez arquivos jpeg ou gif, junto com um monte de arquivos de metadados).

<div class="portlet solid author-note-portlet">é usado por um site (Royal Road) para que os autores incluam uma nota com um capítulo. Alguns autores o usam com moderação e inserem notas curtas sobre o capítulo ou o livro ou anúncios breves sobre coisas aleatórias, talvez com um link para sua página do patreon... tudo bem, não é grande coisa.

Outros o usam para adicionar uma nota de meia página com links para 10 de seus outros livros no início de cada capítulo e novamente para adicionar três páginas e meia de links (com imagens de capa) a esses livros no final de cada capítulo. O que é meio bom se você estiver lendo em forma de série capítulo por capítulo no site, mas não se estiver lendo como um livro - ~ 4 páginas de autopromoção para cada 6-10 ou então as páginas da história são excessivas e distrativas. E, BTW, são 4 "páginas" no meu tablet Android de 10 polegadas - é mais que o dobro no meu telefone.

Eu posso facilmente adicionar display: noneà folha de estilo do epub para esta classe, mas eu quero realmente excluir os divs dos arquivos .xhtml. Eles aumentam notavelmente o tamanho do arquivo .epub.

(**) extrair o conteúdo do .epub com descompactação e reconstruí-lo posteriormente está fora do escopo desta questão, portanto, não se distraia com detalhes irrelevantes. Já tratado.

Exemplo de arquivo .xhtml, editado ao mínimo (e história/capítulo/nome do autor anonimizado para proteger o "culpado :-):

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Chapter Five - Chapter Name</title>
<link href="stylesheet.css" type="text/css" rel="stylesheet"/>
<meta name="chapterurl" content="https://www.royalroad.com/fiction/URL"/>
<meta name="chapterorigtitle" content="Chapter Five - Chapter Name"/>
<meta name="chaptertoctitle" content="Chapter Five - Chapter Name"/>
<meta name="chaptertitle" content="Chapter Five - Chapter Name"/>
</head>
<body class="fff_chapter">
<h3 class="fff_chapter_title">Chapter Five - Chapter Name</h3>
<div class="chapter-inner chapter-content"><div class="portlet solid author-note-portlet">
                    <div class="portlet-title">
                        <div class="caption">
                            <i class="fa fa-sticky-note"></i>
                            <span class="caption-subject bold uppercase">A note from Author Name</span>
                        </div>
                    </div>
                    <div class="portlet-body author-note"><p><span>About a dozen or so p, span, img, and br tags here</span></p>
</div>
                </div>
<p> story text here.  a few hundreds p, br, etc tags
</p>
            <div class="portlet solid author-note-portlet">
                    <div class="portlet-title">
                        <div class="caption">
                            <i class="fa fa-sticky-note"></i>
                            <span class="caption-subject bold uppercase">A note from Author Name</span>
                        </div>
                    </div>
                    <div class="portlet-body author-note"><p>several dozen more p, span, br, img, etc tags here</p>
</div>
                </div>
</div>
</body>
</html>

Talvez eu ainda não tenha tomado café suficiente hoje, mas não consigo me lembrar ou pensar em nenhuma razão pela qual /proc/PID/cmdlinedeveria ser legível pelo mundo - afinal, /proc/PID/environnão é.

Torná-lo legível apenas pelo usuário (e talvez pelo grupo e pelo root, é claro) evitaria a exposição casual de senhas inseridas como argumentos de linha de comando.

Claro, isso afetaria outros usuários executando pse htopsimilares - mas isso é uma coisa boa, certo? Esse seria o ponto de não torná-lo legível para o mundo.

Tenho notado muitas perguntas e respostas e comentários expressando desdém por (e às vezes até medo de) escrever scripts em vez de frases curtas. Então, gostaria de saber:

• Quando e por que devo escrever um script autônomo em vez de um "one-liner"? Ou vice-versa?

• Quais são os casos de uso e os prós e contras de ambos?

• Algumas linguagens (por exemplo, awk ou perl) são mais adequadas para one-liners do que outras (por exemplo, python)? Se sim, por quê?

• É apenas uma questão de preferência pessoal ou existem boas razões (ou seja, objetivas) para escrever um ou outro em circunstâncias particulares? Quais são esses motivos?

Definições

• one-liner: qualquer sequência de comandos digitados ou colados diretamente em uma linha de comando do shell . Muitas vezes envolvendo pipelines e/ou uso de linguagens como sed, awk, perl, e/ou ferramentas como grepou cutou sort.

  É a execução direta na linha de comando que é a característica definidora - o comprimento e a formatação são irrelevantes. Um "one-liner" pode estar todo em uma linha, ou pode ter várias linhas (por exemplo, sh for loop, ou código awk ou sed incorporado, com feeds de linha e recuo para melhorar a legibilidade).

• script: qualquer sequência de comandos em qualquer idioma(s) interpretado(s) que são salvos em um arquivo e, em seguida, executados. Um script pode ser escrito inteiramente em um idioma, ou pode ser um wrapper de shell-script em torno de vários "one-liners" usando outros idiomas.

Eu tenho minha própria resposta (que postarei mais tarde), mas quero que isso se torne um Q&A canônico sobre o assunto, não apenas minha opinião pessoal.