Início / unix / Perguntas / 777642
Accepted
Krackout
Asked: 2024-06-03 18:30:39 +0800 CST

sed em conjunto com xargs e grep não funciona

  • 772

Estou tentando alterar uma string em vários arquivos de texto (configurações migradas para outro usuário). Eu usei este comando:

grep -iIlr "/home/user/.local" | xargs sed -i 's/\/home\/user\/\.local/~\/\.local/g'

também tentei isso:

grep -iIlr "/home/user/.local" | xargs -d '\n' sed -i "s/\/home\/user\/\.local/~\/\.local/g"

Eles não funcionam. Erros são produzidos por sed , a saída do comando é:

sed: can't read dir/file1: No such file or directory
sed: can't read dir/file2: No such file or directory
...
sed: can't read dir/file99: No such file or directory

O erro é produzido para cada arquivo (99 no total). O dir/file1..99 retornado é válido, é o caminho e nome de arquivo adequados para os arquivos.

grep sozinho produz a lista adequada de arquivos. Não há caracteres especiais nos nomes dos arquivos, acho que também não há espaços (não tenho certeza sobre isso). O xargs não está passando uma lista adequada?

SO: RHEL 8.10 totalmente atualizado,
GNU grep v 3.1,
GNU sed 4.5,
xargs (GNU findutils) 4.6.0

Adicionando a saída (exemplo das últimas linhas) do grep -iIlr "/home/user/.local"comando.

senha,~/.local/pipx

venvs/pipx/bin/pipx
venvs/pipx/bin/activate.fish
venvs/pipx/bin/activate-global-python-argcomplete
venvs/pipx/bin/activate.csh
venvs/pipx/pyvenv.cfg
venvs/pipx/lib/python3.11/site-packages/pipx_shared.pth
shared/bin/pip3.11
shared/bin/activate
shared/bin/pip3
shared/bin/pip
shared/bin/wheel
shared/bin/activate.fish
shared/bin/activate.csh
shared/pyvenv.cfg
sed

2 respostas

  1. Best Answer

    Depois que meu cérebro quase derreteu,

    O problema era este:

    $ alias grep
alias grep='grep --color=yes'

    Portanto, a saída do grep incluiu algumas sequências de escape para color que xargs + sed não conseguiu analisar. Meus olhos viram cores bonitas :)

    \grepou unalias grepresolveu o problema.

    • 1

  2. xargspor padrão, espera uma entrada em um formato muito específico, onde os argumentos devem ser separados por caracteres de espaço em branco (cuja lista depende da xargsimplementação e do local, embora no caso do GNU xargsseja limitado a espaço, tabulação e nova linha) e onde único aspas aspas duplas e barra invertida podem ser usadas para escapar delas (embora de uma maneira única).

    Definitivamente, esse não é o formato da lista de arquivos gerados por grep -rl.

    Com -d '\n'(uma extensão GNU), o formato muda para ser delimitado por nova linha, sem nenhuma maneira de escapar da nova linha. Esse é o formato gerado por grep -rl, mas ainda não funciona para nomes de arquivos que contêm caracteres de nova linha. A saída de grep -rlsimplesmente não é pós-processável de forma confiável para nomes de arquivos arbitrários.

    GNU grep(e você já está usando alguns GNUisms) tem uma opção -Z/ para gerar a lista de arquivos de uma forma pós-processável com a qual você pode combinar (também extensões GNU, mas mais portáveis ​​que ):--null-lxargs -r0-d

    grep -rlFIZ /home/user/.local . |
  xargs -r0 sed -Ei 's|/home/user(/\.local)\>|~\1|g'

    Também removi a -iopção de grepque os caminhos de arquivo diferenciam maiúsculas de minúsculas na maioria dos sistemas do tipo Unix, incluindo RHEL e você não está usando o isinalizador para sed's sde qualquer maneira, adicionei a -Fcorrespondência de string fixa for (para evitar ter que escapar do .regexp operador). Adicionado \>o limite do Word para que não corresponda ao /home/user/.localinterior /home/user/.locale, por exemplo (embora ainda corresponda ao interior /home/user/.local-tmp), especificou explicitamente em qual diretório rprocurar ecursivamente (para maior clareza e compatibilidade com versões mais antigas do GNU grep) e adicionou algumas capturas, recuperadas com \1.

    Seu problema foi explicado por você ter um grep='grep --color=yes'alias em vez de grep='grep --color=auto'ou grep='grep --color'o que significa que grepas saídas colorem sequências de escape mesmo quando sua saída não vai diretamente para um terminal.

    Existem outras explicações possíveis.

    Os arquivos ~/.localsão gravados por muitos aplicativos, os arquivos são adicionados e removidos à vontade por eles; entre grepencontrar arquivos e sedprocessá-los, alguns desses arquivos poderiam muito bem ter desaparecido.

    Cuidado também, sed -inão edita arquivos ino local, ele os substitui por uma cópia editada. Se alguns aplicativos tiverem os arquivos que você está editando abertos, eles continuarão vendo a cópia original (agora excluída) e qualquer alteração que fizerem a partir de agora será perdida.

    sed -itambém quebra links físicos e links simbólicos (embora o GNU grep -rnão analise links simbólicos).

    Substituir /home/userpor ~também muitas vezes não é uma coisa válida a se fazer. A expansão do til é algo feito por shells (a maioria dos shells atualmente) e alguns outros aplicativos, mas certamente não todos. Fora deles, ~/.local/fileé chamado o caminho do filearquivo dentro do .localsubdiretório de um subdiretório do diretório de trabalho atual ~(como after mkdir -p '~/.local' && touch '~/.local/file'). Portanto, a substituição /home/user/.localpor ~/.localprovavelmente interromperá muitos aplicativos.

    Lembre-se também de que o GNU grep -Ipara pular arquivos binários usa heurística e não é infalível (de qualquer forma, pode fornecer falsos positivos e falsos negativos). Alguns formatos baseados em texto, como o formato de serialização de dados PHP, serão quebrados se você substituir uma string por outra de comprimento diferente.

    • 1

relate perguntas