Fonds Linux
  1. Fonds Linux
  3. Qu'est-ce qui gouverne les limites de l'expansion de l'accolade?
Intereting Posts
Dans un script, vérifiez si l'input standard provient d'un file ou d'une pipe Combiner la sortie de plusieurs process indépendants dans un autre terminal Empêcher la partition cryptée de s'exécuter sur un autre PC Utilisez dpkg pour afficher le journal des modifications Obtenir le niveau de volume actuel dans OS X Terminal CLI? Vérification et modification de l'autorisation de file avec le script Comment puis-je résoudre un handle nfs périmé? Pourquoi ne puis-je pas modifier directement les liens et les directorys? Qu'est-ce qu'un système de fenêtrage? Comment réparer "login: no shell: No tel file ou directory" quand je ne peux même pas me connecter? Libérer initramfs ram après avoir changé de racine en utilisant overlayfs? Diviser en plusieurs files en fonction de la première colonne lorsque les plages numériques sont appariées dans une autre colonne avec awk Obtenir le numéro et les noms des windows dans Xvfb Concaténer la table sans en-tête Et si 'kill -9' ne fonctionne pas?

Qu'est-ce qui gouverne les limites de l'expansion de l'accolade?

Dans cet exemple, je me réfère à l'expansion d'une suite d'entiers, mais peut-être (?) Les limites seraient pertinentes pour tous les aspects de l'expansion de l'accolade. Cette vue plus générale m'intéresse aussi.

seq semble gérer des suites d'entiers beaucoup plus longues que l'expansion d'accolade {1..n} (du less, c'est le cas dans cet exemple).

par exemple 'seq -f @% 12.0f 1 1000000000> / dev / null' .. Cela augmente de 1 milliard tout à fait heureusement dans 14m 04s

Cependant, echo {1..10000000000} >/dev/null bloque dans l'oubli de la CLI dans 'gnome-terminal' et 'konsole' (… au revoir session terminal!)

Le meilleur que je pourrais get de l'expansion de l'accolade pour une séquence entière, est d'environ {1..15000000} .. seulement 15 millions.

Est-ce une limitation de l'expansion de l'accolade elle-même, ou de la façon dont l' echo gère datatables étendues? Il semble être causé par l'utilisation de toute la RAM disponible, mais je pensais qu'il utiliserait la zone de swap à ce moment-là …

Aussi (btw), cette séquence entière de 15000000, echo {..} prend 57.0s; alors que seq prend seulement 12.7s …

echo {1..5} est développé dans la command echo 1 2 3 4 5 qui est ensuite développée de la manière habituelle. Ce n'est pas du tout similaire à seq 1 1000000000 >/dev/null , qui ne se développe jamais en une command avec de très nombreux arguments.

C'est plus comme echo $(seq 1 1000000000) : Je suppose que ça casse de la même façon?

Le problème que vous rencontrez concerne le traitement des commands volumineuses, dont Unix a toujours été accablant, c'est-à-dire qu'il s'agit d'un problème général lié au traitement des strings de command. C'est une des choses que Perl a été écrite pour réparer.

Je déposerais un rapport de bug poli et informatif de toute façon: cela pourrait provoquer une discussion intéressante.

Je suppose que cette extension n'est pas conçue pour être utilisée de cette façon. L'accident indique un bug, sûrement, mais rarement déclenché.

Dans quelle mesure pensez-vous qu'il faut nourrir des milliards d'entiers consécutifs?