De acordo com a página de manual para lesskey, as seguintes chaves estão vinculadas à rolagem à esquerda e à rolagem à direita:

\e[       left-scroll
\e]       right-scroll
\e(       left-scroll
\e)       right-scroll
\kl       left-scroll
\kr       right-scroll

As teclas de seta e Esc-(/ Esc -)funcionam bem, assim como Esc-]para rolar para a direita, mas Esc-[não para rolar para a esquerda. Em vez disso, apenas mostra isso no prompt da linha de comando:

ESC[

Adicionando esta linha às ~/.lesskeyfunções como uma solução alternativa:

\e[ left-scroll

Mas por que não funciona por padrão?

Eu observei esse comportamento no XFCE4 no trecho Debian, bem como no Kubuntu 18.04, bem como em uma variedade de emuladores de terminal.

$ less --version
less 487 (GNU regular expressions)
Copyright (C) 1984-2016  Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

Eu considerei enviar um relatório de bug, mas a lista de bugs conhecidos e solicitações de recursos sugere que é um comportamento conhecido:

Solicitações de aprimoramento

[. . . ]

Número de referência: 175

Implementado na versão: 322

Adicionar comando alternativo para ESC-[.

Isso é realmente uma limitação no less, ou é uma peculiaridade em como os terminais lidam com a tecla Escape?

Estou tentando depurar um comportamento de desempenho peculiar no processo de geração de miniaturas para eog, especificamente gdk-pixbuf. Os arquivos mínimos para reproduzir estão aqui:

https://github.com/nbeaver/gdk-pixbuf-bug

A árvore de processos fica assim:

systemd,1 splash
  `-plasmashell,4366
      `-konsole,6783
          `-bash,6793
              `-make,6949 reproduce
                  `-eog,6973 /usr/share/doc/docutils-doc/docs/user/images
                      `-bwrap,10071 --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib64 /lib64 --ro-bind /lib /lib --ro-bind /sbin /sbin --proc /proc --dev /dev --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-2HUN5Z /tmp --ro-bind /usr/share/doc/docutils-doc/docs/user/images/s5-files.svg /tmp/gnome-desktop-file-to-thumbnail.svg --seccomp 11 /usr/bin/gdk-pixbuf-thumbnailer -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png
                          `-bwrap,10074 --ro-bind /usr /usr --ro-bind /bin /bin --ro-bind /lib64 /lib64 --ro-bind /lib /lib --ro-bind /sbin /sbin --proc /proc --dev /dev --chdir / --setenv GIO_USE_VFS local --unshare-all --die-with-parent --bind /tmp/gnome-desktop-thumbnailer-2HUN5Z /tmp --ro-bind /usr/share/doc/docutils-doc/docs/user/images/s5-files.svg /tmp/gnome-desktop-file-to-thumbnail.svg --seccomp 11 /usr/bin/gdk-pixbuf-thumbnailer -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png
                              `-gdk-pixbuf-thum,10075 -s 128 file:///tmp/gnome-desktop-file-to-thumbnail.svg /tmp/gnome-desktop-thumbnailer.png

Do stracelog , parece que /usr/bin/gdk-pixbuf-thumbnailerestá gastando cerca de 30 segundos olhando os arquivos de fonte:

22:44:05 munmap(0x7fd491988000, 20930832) = 0 <0.000558>
22:44:05 openat(AT_FDCWD, "/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc", O_RDONLY) = 5 <0.000060>
22:44:05 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000014>
22:44:05 fstat(5, {st_mode=S_IFREG|0644, st_size=20930832, ...}) = 0 <0.000013>
22:44:05 mmap(NULL, 20930832, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd491988000 <0.000021>
22:44:05 close(5)                       = 0 <0.000011>
22:44:06 munmap(0x7fd491988000, 20930832) = 0 <0.000525>
22:44:06 openat(AT_FDCWD, "/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc", O_RDONLY) = 5 <0.000076>
22:44:06 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000013>
22:44:06 fstat(5, {st_mode=S_IFREG|0644, st_size=20930832, ...}) = 0 <0.000012>
22:44:06 mmap(NULL, 20930832, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd491988000 <0.000023>
22:44:06 close(5)                       = 0 <0.000013>
<snip>
22:44:31 stat("/usr/share/fonts/opentype/stix-word/STIXMath-Regular.otf", {st_mode=S_IFREG|0644, st_size=476872, ...}) = 0 <0.000024>
22:44:31 openat(AT_FDCWD, "/usr/share/fonts/opentype/stix-word/STIXMath-Regular.otf", O_RDONLY) = 5 <0.000026>
22:44:31 fcntl(5, F_SETFD, FD_CLOEXEC)  = 0 <0.000014>
22:44:31 fstat(5, {st_mode=S_IFREG|0644, st_size=476872, ...}) = 0 <0.000013>
22:44:31 mmap(NULL, 476872, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7fd49c26a000 <0.000023>
22:44:31 close(5)                       = 0 <0.000015>

Existe um SVG específico que aciona esse comportamento. No entanto, não basta apenas rodar eog ou gdk-pixbuf-thumbnailerno SVG. Esse comportamento só acontece quando:

• rodando eogem um diretório;

• existe um SVG específico no diretório que ainda não possui uma miniatura em ~/.cache/thumbnails/.

  (Eu uso touchpara atualizar o timestamp do SVG e fazer o thumbnailer rodar novamente todas as vezes.)

• há pelo menos uma outra imagem no mesmo diretório;

• e a outra imagem tem um nome de arquivo que agrupa antes do nome de arquivo SVG.

  (Se o nome do arquivo for agrupado após o nome do arquivo SVG, ele gerará a miniatura em menos de um segundo. Caso contrário, levará cerca de 30 segundos.)

Existem alguns outros quebra-cabeças também. No stracelog , os tempos do relógio de parede não parecem corresponder ao tempo gasto nas chamadas do sistema. Eu corri eogcom stracea -fbandeira:

-f

Rastreie processos filhos conforme eles são criados por processos atualmente rastreados como resultado das chamadas de sistema fork(2), vfork(2) e clone(2).

e eu também tentei o -ffsinalizador:

-ff

Se a -o filenameopção estiver em vigor, cada rastreamento de processo será gravado filename.pidonde pidestá o ID numérico do processo de cada processo.

mas em ambos os casos gdk-pixbuf-thumbnailernão aparece nos arquivos de log dos processos filhos.

Também estou tendo problemas para executar (algo gdbsobre gdk-pixbuf-thumbnailer "O destino e o depurador estão em namespaces PID diferentes"), então não posso dizer onde está ficando preso.

$ sudo gdb -p 20789
[sudo] password for nathaniel:
<snip>
Error while mapping shared library sections:
Could not open `target:/lib/x86_64-linux-gnu/libbsd.so.0' as an executable file: No such file or directory

warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

warning: Target and debugger are in different PID namespaces; thread lists and other data are likely unreliable.  Connect to gdbserver inside the container.
(gdb) quit
Detaching from program: target:/newroot/usr/bin/gdk-pixbuf-thumbnailer, process 20789

Eu estou supondo que isso tem a ver com o bwraprecipiente.

Versão informação:

$ apt-cache policy libgdk-pixbuf2.0-bin eog
libgdk-pixbuf2.0-bin:
  Installed: 2.36.11-2
  Candidate: 2.36.11-2
  Version table:
 *** 2.36.11-2 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
eog:
  Installed: 3.28.1-1
  Candidate: 3.28.1-1
  Version table:
 *** 3.28.1-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

Minhas perguntas são:

• Este bug é reproduzível em outras máquinas e outras versões?

  (Acontece que estou usando o Ubuntu 18.04, mas quero saber se isso acontece em outras distribuições.)

• Por que não está strace -fpegando /usr/bin/gdk-pixbuf-thumbnailer como um processo filho de eog?

  Usa eogum método incomum para criar processos filho?

• Como posso usar gdbpara anexar ao /usr/bin/gdk-pixbuf-thumbnailerprocesso e ver em qual função ele está gastando tempo?

• O que pode estar causando esse comportamento?

Considere um comando que pesquisa em todo o diretório inicial um arquivo ou diretório com as permissões erradas:

$ find $HOME -perm 777

Este é apenas um exemplo; o comando pode estar listando links simbólicos quebrados:

$ find $HOME -xtype l

ou listando links simbólicos longos:

$ symlinks -s -r $HOME

ou qualquer número de outros comandos caros que enviam caminhos delimitados por nova linha para stdout.

Agora, eu poderia reunir os resultados em um pager como este:

$ find $HOME -perm 777 | less

e, em seguida, cdpara os diretórios relevantes em um terminal virtual diferente. Mas eu prefiro ter um script que abra um novo shell interativo para cada linha de saída, assim:

$ find $HOME -perm 777 | visit-paths.sh

Dessa forma, posso, por exemplo, inspecionar cada arquivo ou diretório, verificar o carimbo de data/hora, decidir se preciso alterar as permissões ou excluir arquivos, etc.

É possível com um script bash que lê caminhos de um arquivo ou de stdin , assim:

#! /usr/bin/env bash

set -e

declare -A ALREADY_SEEN
while IFS='' read -u 10 -r line || test -n "$line"
do
    if test -d "$line"
    then
        VISIT_DIR="$line"
    elif test -f "$line"
    then
        VISIT_DIR="$(dirname "$line")"
    else
        printf "Warning: path does not exist: '%s'\n" "$line" >&2
        continue
    fi
    if test "${ALREADY_SEEN[$VISIT_DIR]}" != '1'
    then
        ( cd "$VISIT_DIR" && $SHELL -i </dev/tty )
        ALREADY_SEEN[${VISIT_DIR}]=1
        continue
    else
        # Same as last time, skip it.
        continue
    fi
done 10< "${*:-/dev/stdin}"

Isso tem alguns pontos positivos, como:

• O script abre um novo shell assim que uma nova linha de saída aparece no stdin. Isso significa que não preciso esperar que o comando slow termine completamente antes de começar a fazer as coisas.

• O comando slow continua sendo executado em segundo plano enquanto estou fazendo coisas no shell recém-gerado, então o próximo caminho está potencialmente pronto para ser visitado quando eu terminar.

• Eu posso sair do loop mais cedo, se necessário, com, por exemplo false; exit, ou apenas Ctrl-C Ctrl-D.

• O script lida com nomes de arquivos e diretórios.

• O script evita navegar para o mesmo diretório duas vezes seguidas. (Obrigado a @MichaelHomer por explicar como fazer isso com arrays associativos.)

No entanto, há um problema com este script:

• Todo o pipeline é encerrado se o último comando tiver um status diferente de zero, o que é útil para sair antecipadamente, mas em geral requer verificação a $?cada vez para evitar uma saída antecipada acidental.

Para tentar resolver esse problema, escrevi um script Python:

#! /usr/bin/env python3

import argparse
import logging
import os
import subprocess
import sys

if __name__ == '__main__':
    parser = argparse.ArgumentParser(
        description='Visit files from file or stdin.'
    )
    parser.add_argument(
        '-v',
        '--verbose',
        help='More verbose logging',
        dest="loglevel",
        default=logging.WARNING,
        action="store_const",
        const=logging.INFO,
    )
    parser.add_argument(
        '-d',
        '--debug',
        help='Enable debugging logs',
        action="store_const",
        dest="loglevel",
        const=logging.DEBUG,
    )
    parser.add_argument(
        'infile',
        nargs='?',
        type=argparse.FileType('r'),
        default=sys.stdin,
        help='Input file (or stdin)',
    )
    args = parser.parse_args()
    logging.basicConfig(level=args.loglevel)
    shell_bin = os.environ['SHELL']
    logging.debug("SHELL = '{}'".format(shell_bin))
    already_visited = set()
    n_visits = 0
    n_skipped = 0
    for i, line in enumerate(args.infile):
        visit_dir = None
        candidate = line.rstrip()
        logging.debug("candidate = '{}'".format(candidate))
        if os.path.isdir(candidate):
            visit_dir = candidate
        elif os.path.isfile(candidate):
            visit_dir = os.path.dirname(candidate)
        else:
            logging.warning("does not exist: '{}'".format(candidate))
            n_skipped +=1
            continue
        if visit_dir is not None:
            real_dir = os.path.realpath(visit_dir)
        else:
            # Should not happen.
            logging.warning("could not determine directory for path: '{}'".format(candidate))
            n_skipped +=1
            continue
        if visit_dir in already_visited:
            logging.info("already visited: '{}'".format(visit_dir))
            n_skipped +=1
            continue
        elif real_dir in already_visited:
            logging.info("already visited: '{}' -> '{}'".format(visit_dir, real_dir))
            n_skipped +=1
            continue
        if i != 0:
            try :
                response = input("#{}. Continue? (y/n) ".format(n_visits + 1))
            except EOFError:
                sys.stdout.write('\n')
                break
            if response in ["n", "no"]:
                break
        logging.info("spawning '{}' in '{}'".format(shell_bin, visit_dir))
        run_args = [shell_bin, "-i"]
        subprocess.call(run_args, cwd=visit_dir, stdin=open('/dev/tty'))
        already_visited.add(visit_dir)
        already_visited.add(real_dir)
        n_visits +=1

    logging.info("# paths received: {}".format(i + 1))
    logging.info("distinct directories visited: {}".format(n_visits))
    logging.info("paths skipped: {}".format(n_skipped))

No entanto, estou tendo alguns problemas com as respostas ao Continue? (y/n)prompt sendo passado para o shell que é gerado, causando erros como y: command not found. Suspeito que o problema esteja nesta linha:

subprocess.call(run_args, cwd=visit_dir, stdin=open('/dev/tty'))

Preciso fazer algo diferente com o stdinao usar subprocess.call?

Como alternativa, existe uma ferramenta amplamente disponível que torna os dois scripts redundantes da qual eu não ouvi falar?

Posso executar straceum comando como sleep 1 e ver quais arquivos ele está acessando assim:

strace -e trace=file -o strace.log sleep 1

No entanto, na minha máquina, muitas das chamadas têm um valor de retorno de -1, indicando que o arquivo não existe. Por exemplo:

$ grep '= -1 ENOENT' strace.log | head
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/locale/en_US.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Não estou realmente interessado nos arquivos que não existem, quero saber quais arquivos o processo realmente encontrou e leu. Além de grep -v '=-1 ENOENT', como posso filtrar com segurança as chamadas com falha?

Termo aditivo

Fiquei surpreso ao saber que straceesse recurso está em andamento desde 2002 na forma de -zflag, que é um alias para -e status=successful, totalmente funcional desde a versão 5.2 ( 2019-07-12 ), também disponível --successful-only desde a versão 5.6 ( 2020- 04-07 ).

Também disponível desde a versão 5.2 está o complemento de -z, o -Zflag, que é um alias para -e status=failed, disponível --failed-onlydesde a versão 5.6.

O -zsinalizador foi adicionado pela primeira vez em um commit de 2002 e lançado na versão 4.5.18 ( 2008-08-28 ), mas nunca foi documentado porque não estava funcionando corretamente.

links relevantes:

• vendo apenas chamadas de sistema bem-sucedidas

  Sáb 2 de novembro 23:07:23 UTC 2002

  Ao usar o strace, às vezes gosto de ver as chamadas do sistema que funcionam (em vez de todas as chamadas do sistema).

  Eu tenho portado este patch por anos, parece muito útil.

  Com a opção -z, você não vê aberturas em arquivos que não existem (muito útil para rastrear o que um programa realmente faz, em vez de tentar fazer).

  https://lists.strace.io/pipermail/strace-devel/2002-November/000232.html

• strace: a opção -z não funciona corretamente

  Data: Dom, 12 de janeiro de 2003 09:33:01 UTC

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=176376

• rastreando apenas syscalls com falha

  Criado: 2004-03-19

  https://sourceforge.net/p/strace/feature-requests/3/

• [strace-4.15] Proposta: Staging de saída para a opção -z (apenas syscalls de impressão bem-sucedida) / Patch incluído

  Terça-feira, 17 de janeiro 09:35:54 UTC 2017

  https://lists.strace.io/pipermail/strace-devel/2017-January/005941.html

• [PATCH v1] Preparação de saída implementada para syscalls com falha/bem-sucedida

  Qua, 18 de janeiro 16:01:20 UTC 2017

  https://lists.strace.io/pipermail/strace-devel/2017-January/005950.html

• Corrigir opção -z

  28 de fevereiro de 2018

  https://github.com/strace/strace/issues/49

• [PATCH 0/3] Saída de palco para -ze novas opções -Z

  Segunda-feira, 1 de abril 21:13:02 UTC 2019

  https://lists.strace.io/pipermail/strace-devel/2019-April/008706.html

• sinalizador strace -z

  Segunda-feira, 10 de junho 05:29:19 UTC 2019

  https://lists.strace.io/pipermail/strace-devel/2019-June/008808.html

Eu multiarchhabilitei e, quando executo debtags search, recebo muitos resultados duplicados.

$ debtags search 'works-with-format::man' | head
docbook-to-man - converter from DocBook SGML into roff man macros
docbook-to-man:i386 - converter from DocBook SGML into roff man macros
docbook-utils - Convert DocBook files to other formats (HTML, RTF, PS, man, PDF)
docbook2x - Converts DocBook/XML documents into man pages and TeXinfo
docbook2x:i386 - Converts DocBook/XML documents into man pages and TeXinfo
doclifter - Convert troff to DocBook
dwww - Read all on-line documentation with a WWW browser
dwww:i386 - Read all on-line documentation with a WWW browser
ebook-speaker - eBook reader that reads aloud in a synthetic voice
ebook-speaker:i386 - eBook reader that reads aloud in a synthetic voice

Existe uma solução alternativa usando grep:

$ debtags search 'works-with-format::man' | grep -v ':i386 - ' | head
docbook-to-man - converter from DocBook SGML into roff man macros
docbook-utils - Convert DocBook files to other formats (HTML, RTF, PS, man, PDF)
docbook2x - Converts DocBook/XML documents into man pages and TeXinfo
doclifter - Convert troff to DocBook
dwww - Read all on-line documentation with a WWW browser
ebook-speaker - eBook reader that reads aloud in a synthetic voice
git-man - fast, scalable, distributed revision control system (manual pages)
gman - small man(1) front-end for X
gmanedit - GTK+ man pages editor
gnulib - GNU Portability Library

Isso pressupõe que a string :i386 -não apareça em nenhuma descrição de pacote, o que é um pouco complicado. Existe uma maneira melhor?

Corro iotoppara verificar os programas que são usuários pesados ​​de disco, caso precise diminuir sua prioridade. Normalmente, isso é bom o suficiente, mas iotopmostra apenas o ID do encadeamento (TID) e, às vezes, quero saber o ID do processo (PID) para descobrir mais sobre qual processo é responsável.

Infelizmente, embora pspossa exibir TID (também conhecido como SPID, LWP), ele não possui um sinalizador para obter uma lista de TIDs da mesma forma que faz para uma lista de PIDs com --pid. O melhor que posso fazer é listar os TIDs e depois grepa saída. Por exemplo, se o ID do thread for 792, posso fazer

$ ps -eLf | grep ' 792 '

que funciona razoavelmente bem, mas é um pouco deselegante.

Existe uma maneira melhor?

Quando os aplicativos segfault, geralmente vejo mensagens como esta em dmesg:

pstree[25678]: segfault at 0 ip 00007f58be0b3ae4 sp 00007ffe65b700a0 error 4 in libc-2.24.so[7f58be04d000+195000]

No entanto, acho que de alguma forma devo ter alterado minhas configurações de kernel em algum lugar, porque não vejo mais essas mensagens em arquivos dmesg. Estou acionando segfaults com este programa C:

#include <signal.h>

int main()
{
        raise(SIGSEGV);
}

Eu sei que meu loglevel está definido em KERN_DEBUG:

$ cat /proc/sys/kernel/printk
7   4   1   7

e sei que posso ver a saída dmesgassim:

sudo sh -c "printf '<%s> Log level %s (KERN_DEBUG)\n' '7' '7' > /dev/kmsg"

e eu sei que debug.exception-traceestá definido como 1:

$ sysctl debug.exception-trace 
debug.exception-trace = 1
$ cat /proc/sys/debug/exception-trace 
1

mas ainda não recebo notificações de segfault. A dmesgpágina de manual fala sobre colorir mensagens de falha de segmentação, mas não sobre ativá-las ou desativá-las.