“Lista de argumentos muito longa”: como faço para lidar com isso sem alterar meu comando?

Quando executo um comando como ls */*/*/*/*.jpg, recebo o erro

-bash: /bin/ls: Argument list too long

Eu sei por que isso acontece: é porque há um limite de kernel na quantidade de espaço para argumentos em um comando. O conselho padrão é alterar o comando que eu uso, para evitar exigir muito espaço para argumentos (por exemplo, use finde xargs).

E se eu não quiser mudar o comando? E se eu quiser continuar usando o mesmo comando? Como faço para que as coisas "funcionem" sem obter esse erro? Que soluções estão disponíveis?

No Linux, a quantidade máxima de espaço para argumentos de comando é 1/4 da quantidade de espaço disponível na pilha. Portanto, uma solução é aumentar a quantidade de espaço disponível para a pilha.

Versão curta: execute algo como

ulimit -s 65536

Versão mais longa: a quantidade padrão de espaço disponível para a pilha é algo como 8192 KB. Você pode ver a quantidade de espaço disponível, da seguinte maneira:

$ ulimit -s
8192

Escolha um número maior e defina a quantidade de espaço disponível para a pilha. Por exemplo, se você quiser tentar permitir até 65536 KB para a pilha, execute o seguinte:

$ ulimit -s 65536

Talvez você precise brincar com o tamanho que isso precisa ser, usando tentativa e erro. Em muitos casos, esta é uma solução rápida e suja que irá eliminar a necessidade de modificar o comando e trabalho fora a sintaxe find, xargsetc. (embora eu percebo que há outros benefícios para fazê-lo).

Eu acredito que isso seja específico do Linux. Eu suspeito que provavelmente não ajudará em nenhum outro sistema operacional Unix (não testado).

Este artigo do Linux Journal fornece 4 soluções. Somente a quarta solução não envolve a alteração do comando:

O método 4 envolve aumentar manualmente o número de páginas alocadas no kernel para argumentos da linha de comando. Se você observar o arquivo include / linux / binfmts.h, encontrará o seguinte na parte superior:

/*
 * MAX_ARG_PAGES defines the number of pages allocated for   arguments
 * and envelope for the new program. 32 should suffice, this gives
 * a maximum env+arg of 128kB w/4KB pages!
 */
#define MAX_ARG_PAGES 32

Para aumentar a quantidade de memória dedicada aos argumentos da linha de comando, você simplesmente precisa fornecer o valor MAX_ARG_PAGES com um número maior. Depois que essa edição é salva, basta recompilar, instalar e reiniciar no novo kernel, como faria normalmente.

No meu próprio sistema de teste, consegui resolver todos os meus problemas aumentando esse valor para 64. Após testes extensivos, não tive um único problema desde a troca. Isso é totalmente esperado, já que, mesmo com MAX_ARG_PAGESdefinido como 64, a maior linha de comando possível que eu poderia produzir ocuparia apenas 256 KB de memória do sistema - não muito pelos padrões de hardware do sistema de hoje.

As vantagens do método # 4 são claras. Agora você pode simplesmente executar o comando como faria normalmente, e ele é concluído com êxito. As desvantagens são igualmente claras. Se você aumentar a quantidade de memória disponível para a linha de comando além da quantidade de memória disponível no sistema, poderá criar um ataque do DOS no seu próprio sistema e causar uma falha. Em sistemas multiusuário, em particular, mesmo um pequeno aumento pode ter um impacto significativo, pois cada usuário recebe a memória adicional. Portanto, sempre teste extensivamente em seu próprio ambiente, pois essa é a maneira mais segura de determinar se o Método 4 é uma opção viável para você.

Concordo que a limitação é seriamente irritante.

Em vez de ls */*/*/*/*.jpg, tente:

echo */*/*/*/*.jpg | xargs ls

xargs(1) sabe qual é o número máximo de argumentos no sistema e interromperá sua entrada padrão para chamar a linha de comando especificada várias vezes, sem mais argumentos que esse limite, qualquer que seja (você também pode configurá-lo abaixo de máximo do sistema operacional usando a -nopção).

Por exemplo, suponha que o limite seja de 3 argumentos e você tenha cinco arquivos. Nesse caso, xargsserá executado lsduas vezes:

1. ls 1.jpg 2.jpg 3.jpg
2. ls 4.jpg 5.jpg

Geralmente isso é perfeitamente adequado, mas nem sempre - por exemplo, você não pode confiar em ls(1) classificar todas as entradas para você corretamente, porque cada lsconvite -in separado separará apenas o subconjunto de entradas atribuído a ele xargs.

Embora você possa aumentar o limite conforme sugerido por outras pessoas, ainda haverá um limite - e um dia sua coleção de JPG superará isso novamente. Você deve preparar seu script para lidar com um número infinito ...