Início / computer / Perguntas / 1848192
Accepted
RokeJulianLockhart
Asked: 2024-07-06 00:46:25 +0800 CST

Por que os caminhos UTF-8 escapam (de maneira diferente) nas saídas dos principais utilitários CLI?

  • 772

Digamos que sou um psicopata que nomeia meus arquivos como:

  [-]   `{title: "Non-Metadata",    id: "s4a4ji"}`{.JSON5}.dir

Essa é a minha melhor tentativa de criar o nome de arquivo mais horrível e plausível possível - ele usa Pandoc Markdown e JSON5.

POSIX

Se eu inserir isso ls, ele me fornecerá uma versão que pode ser escapada de forma que qualquer shell compatível com POSIX (sh, é claro, mas também bash, no Fedora 40) seja capaz de interpretá-lo sem problemas:

  1. ls "$PWD"

  2. '  [-]'$'\t''`{title: "Non-Metadata",'$'\t''id: "s4a4ji"}`{.JSON5}.dir'
Octeto

No entanto, treee fileem vez disso, parece substituir caracteres não ASCII por um tipo de representação com escape de octeto, que não parece ser utilizável da maneira descrita acima:

  1. tree "$PWD"

  2. .
└──   [-]\011`{title: "Non-Metadata",\011id: "s4a4ji"}`{.JSON5}.dir

2 directories, 0 files
UTF-8

E, claro, o PowerShell Core Get-ChildItemapenas gera a representação UTF-8 completa:

  1. Get-ChildItem -LiteralPath "$PWD" | Select-Object -ExpandProperty 'Name'

  2.   [-]   `{title: "Non-Metadata",        id: "s4a4ji"}`{.JSON5}.dir

Como é que estes funcionam de forma diferente? Eu esperaria que ls, tree, e filepelo menos operassem de forma idêntica, considerando que - até onde sei - estes são GNU CoreUtils. Além disso, o PowerShell parece demonstrar que nada força fundamentalmente essas ferramentas a escapar de caracteres não-ASCII, então por que estão fazendo isso?

powershell

1 respostas

  1. Best Answer

    POSIX

    Até onde sei, essa não era a sintaxe POSIX no momento em que sua versão lsfoi lançada; o $'...'único passou a fazer parte do POSIX 2024 na semana passada; até então, era apenas um recurso de sintaxe ksh amplamente adotado.

    No entanto, árvore e arquivo parecem substituir caracteres não-ASCII por uma espécie de representação com escape de octeto

    Esta é uma representação octal , usando uma sintaxe que imita literais de string C. (Que suportam hexadecimal, mas octal é "tradicional" de certa forma.) Acho que esse é o estilo que o libbsd strvis()usa por padrão.

    Além disso, esses não são caracteres "não-ASCII": as guias fazem parte do ASCII, que cobre todos os valores de bytes de 0 a 127. Valores de bytes acima de 127 (0x7F, 0177) seriam não-ASCII.

    Como é que estes funcionam de forma diferente?

    São três programas diferentes, simples assim. Não existe uma função comum para "gerar um nome de arquivo" - cada programa aplica o escape que deseja antes de gravá-lo no stdout. (É aqui também que os estilos GNU e BSD diferem.)

    Eu esperaria que ls, tree e file operassem pelo menos de forma idêntica, considerando que - até onde sei - estes são GNU CoreUtils.

    Não, eles não são. Apenas lso GNU coreutils – os outros dois nem sequer estão sob a égide do GNU.

    Além disso, o PowerShell parece demonstrar que nada força fundamentalmente essas ferramentas a escapar de caracteres não-ASCII, então por que estão fazendo isso?

    Os programas também podem fazer coisas sem serem “fundamentalmente forçados” a fazê-lo. Muitos programas escapam deliberadamente de pelo menos os caracteres de controle ASCII C0 para que não sejam (mal) interpretados pelos terminais, por exemplo.

    Coreutils' lssempre teve uma seleção de --quoting-styles com a intenção de tornar os caracteres 'inválidos' mais fáceis de distinguir e (a partir da versão 9.0, se bem me lembro) deliberadamente usa como padrão aspas no estilo Bash para que tais nomes de arquivos possam ser diretamente copie/cole no shell GNU.

    (Veja também a ferramenta histórica do Unix dswe vários outros truques que as pessoas tiveram que usar para remover um arquivo com um nome de arquivo não digitável.)

    O PowerShell, por outro lado, nem sequer considera a string um nome de arquivo: é apenas uma propriedade com valor de string de algum objeto. Quando o objeto inteiro (o resultado de Get-ChildItem) é formatado como stdout, ele aplica algum escape, mas as propriedades individuais não sabem nada sobre sua localização.

    treeapenas faz um esforço básico para evitar que caracteres de controle ASCII tenham efeitos indesejáveis ​​em seu terminal, mas não visa especificamente a capacidade de cópia.

    • 1

relate perguntas