Início / user-377345

AdminBee's questions

Martin Hope
AdminBee
Asked: 2023-08-25 19:16:27 +0800 CST
  • 9

Eu queria usar trpara substituir caracteres "ilegais" em uma string por um caractere de substituição, onde os caracteres "ilegais" estão todos fora de um conjunto de caracteres "permitidos" (ou seja, são o complemento do conjunto de caracteres permitidos). No entanto, ao usar a -copção e o *especificador de repetição explícito ou a extensão implícita do "conjunto 2", tranexa uma instância adicional do caractere de substituição à saída.

Reproduzir

  • Sejam os caracteres "permitidos" a-n, especificados literalmente como abcdefghijklmn.
  • Deixe o caractere de substituição ser z.
  • Deixe a string de entrada ser hellou hello. A string de saída esperada é então helle hellz, respectivamente.

Demonstração

  1. Caracteres ilegais presentes, extensão implícita do conjunto 2

    $ echo "hello" | tr -c 'abcdefghijklmn' 'z'
hellzz

    A saída esperada é hellz.

  2. Somente caracteres permitidos presentes, extensão implícita do conjunto 2

    $ echo "hell" | tr -c 'abcdefghijklmn' 'z'
hellz

    A saída esperada é hell.

  3. Caracteres ilegais presentes, extensão explícita do conjunto 2

    $ echo "hello" | tr -c 'abcdefghijklmn' '[z*]'
hellzz

    A saída esperada é hellz.

  4. Somente caracteres permitidos presentes, extensão explícita do conjunto 2

    $ echo "hell" | tr -c 'abcdefghijklmn' '[z*]'
hellz

    A saída esperada é hell.

  5. O mesmo acontece quando eu uso uma string here em vez de echo-pipe (na verdade, a string here foi a construção que usei quando me deparei com esse efeito pela primeira vez):

    $ tr -c 'abcdefghijkl' '[z*]' <<< "hello"
hellzz

Por que tracrescenta um adicional zaqui?

Isso está no Linux, com bash, localidade UTF-8 e trno GNU coreutils 8.25 e 8.30.

text-processing
Martin Hope
AdminBee
Asked: 2022-09-29 07:52:37 +0800 CST
  • 1

O OracleLinux 8.6 contém o pacote de 32 bits glibc-2.28-189.1.0.1.el8.i686.rpm. Este pacote requer glibc-commonexatamente essa versão:

$ rpm -qpv --requires glibc-2.28-189.1.0.1.el8.i686.rpm 
...
manual: glibc-common = 2.28-189.1.0.1.el8
...

No entanto, os repositórios não contêm glibc-common-2.28-189.1.0.1.el8.i686.rpm, apenas glibc-common-2.28-189.1.0.1.el8.x86_64.rpm.

A versão de 64 bits pode atender ao requisito de dependência do pacote glibc-commonde 32 bits ? glibcEm caso afirmativo, por que não é considerado noarche como o resolvedor de dependência RPM descobriria que precisa extrair a variante de 64 bits do pacote RPM?

Alternativamente, existe um repositório no qual exatamente esta versão glibc-common.i686é fornecida? Estou ciente do repositório Koji , mas isso fornece apenas glibc-common-2.28-189.el8.i686.rpm, não 2.28-189.1.0.1.el8 .

rpm dependencies
Martin Hope
AdminBee
Asked: 2019-10-16 23:30:09 +0800 CST
  • 0

Estou tentando implementar uma função personalizada que, ao anexar uma unidade USB, verifica todos os sistemas de arquivos que ela contém e, em seguida, executa operações com base no tipo de sistema de arquivos detectado. Eu segui o caminho "recomendado" para escrever uma udevregra que aciona um systemdserviço "oneshot" instanciado para o nó do dispositivo, que por sua vez executa o script de shell que "faz toda a mágica (TM)" (por razões de independência de plataforma, um compilado programa não foi considerado uma opção aqui).

ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", RUN{program}="/bin/systemctl start usb-drive-manager@$devnode.service"

com

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/usb_drive_manager.sh attach %I
ExecStop=/usr/local/bin/usb_drive_manager.sh detach %I

Dentro do script de shell, executo um ls /sys/.../sdX/sdX*caminho no dispositivo da unidade para localizar quaisquer partições e, em seguida, consultar informações sobre essas partições chamando

udevadm info /dev/sdXn

(onde né o número da partição) para cada partição processada.

O problema agora é que, embora isso funcione durante os testes "coldplug" do script de shell, não funciona quando o script é acionado a partir da udevregra, porque no momento em que o udevevento para a unidade é processado, as informações sobre as partições na unidade são ainda não coletado pelo kernel, ou seja, a chamada para udevadm inforetorna apenas informações rudimentares:

P: /devices/.../block/sdb/sdb1
N: sdb1
E: DEVNAME=/dev/sdb1
E: DEVPATH=/devices/.../block/sdb/sdb1
E: DEVTYPE=partition
E: MAJOR=8
E: MINOR=17
E: SUBSYSTEM=block

e todas as informações relevantes, em particular as variáveis ​​de ambiente ID_FS_TYPEe estão (ainda) ausentes. ID_FS_LABELComo chamar udevadm settledurante o processamento de udeveventos é uma má ideia (e também não ajudou), e até mesmo um loop de pesquisa com 0,5s de sono entre as chamadas para udevadm infonão funcionou (demorou cerca de 1 minuto até que a informação estivesse finalmente disponível), eu estou um pouco perdido aqui.

Infelizmente, reescrever a udevregra para que ela se aplique a partições em vez de unidades também é indesejável, pois há casos em que as pessoas criam o sistema de arquivos em todo o dispositivo USB em vez de criar uma única partição que abrange todo o dispositivo que contém o sistema de arquivos.

A questão agora é se

  • é possível atrasar o processamento de uma udevregra para um determinado dispositivo até que todos os filhos desse dispositivo tenham sido processados, ou
  • há uma chamada de sistema que eu poderia usar dentro do script de shell que "espera" que todos os eventos filho (se houver! udev)

Acho que esta é uma pergunta bastante longa agora; toda a ajuda é muito apreciada.

shell-script