Discussion :

[NeoType]

Salut,
J'ai une question purement théorique.

J'ai tendance à préférer stocker le résultat de commandes aussi souvent que possible dans des variables y compris là où il pourrait être tentant d'utiliser des fichiers temporaires.

Typiquement par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
resultat=$(ls | sed 's/^/prefixe/')

Ce qui présente pas mal d'avantages: rapidité, éviter la gestion des droits d'accès disque, conflits potentiels avec des fichiers existants, etc

Par contre quid de la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
resultat=$(cat video_de_50Go.avi)

Ca fait boum ? ^^

(Tu me diras que je n'ai qu'à tester pour voir...)

[N_BaH]

mais qui veut stocker le contenu d'un fichier .avi dans une variable ?

et qui utilise ls dans un script ?!

[Flodelarab]

Bonjour

mais qui veut stocker le contenu d'un fichier .avi dans une variable ?

Tous ceux qui viennent de la programmation objet et qui considèrent le pointeur comme le point d'entrée absolu pour désigner quoi que ce soit. On retrouve ces codeurs en scripts, et on doit leur expliquer qu'en programmation shell, ce sont des mauvais réflexes. Du moins des maladresses.

Ca fait boum ?

Sur le fond, la substitution de commande $( ) sert à récupérer du texte. Le contenu d'un fichier *.avi n'est probablement pas du texte. Donc la commande est inadéquate.

[Sve@r]

Bonjour

J'ai tendance à préférer stocker le résultat de commandes aussi souvent que possible dans des variables y compris là où il pourrait être tentant d'utiliser des fichiers temporaires.

Jusque là, je ne vois pas de souci. On fait tous la même chose. Je te recommanderais toutefois de quoter ta variable pour éviter toute interprétation éventuelle qui viendrait modifier le résultat de ta commande avant sa copie dans la variable => resultat="$(ta commande)".

Ce qui présente pas mal d'avantages: rapidité, éviter la gestion des droits d'accès disque, conflits potentiels avec des fichiers existants, etc

Ben si la gestion des noms des fichiers temporaires est bien faite (utilisation de "/tmp" et de techniques assurant les noms unique comme "$$" ou "mktemp") tu n'auras aucun souci de droit d'accès ou de collision, seul restera le souci de la vitesse d'accès disque. Et si "/tmp" est monté en RAM alors même ça ça disparait (mais en contrepartie on retombe sur le souci de la taille maximale pouvant être utilisée en RAM)

Par contre quid de la commande suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

resultat=$(cat video_de_50Go.avi)

Ca fait boum ? ^^

C'est une question qui ne dépend que de la puissance de ton ordi. Sur un ordi avec 64Go de RAM, ou bien avec 32Go de RAM et 32Go de swap, ça ne devrait pas faire boum.
Mais dans 99% des cas on n'a pas besoin de mémoriser 50Go pour traiter 50Go. Et je dis "99%" pour laisser la porte ouverte mais franchement je ne vois pas de situation qui nécessiterait de stocker 50Go de data (ou même de façon plus générale qui nécessiterait de stocker tout un fichier même si ce fichier ne pèse que 10ko).

Sur le fond, la substitution de commande $( ) sert à récupérer du texte... Donc la commande est inadéquate.

Non, ça sert à récupérer de la data, ni plus, ni moins. Pourquoi la réduire à du seul texte ? Surtout sur un système Linux qui justement ne fait aucune différence entre texte et binaire !!! La commande fonctionnera parfaitement y compris sur un fichier ".avi".

[Flodelarab]

Non, ça sert à récupérer de la data, ni plus, ni moins. Pourquoi la réduire à du seul texte ? Surtout sur un système Linux qui justement ne fait aucune différence entre texte et binaire !!!

En voilà une belle bêtise. La norme POSIX dit qu'une ligne valide finit par \n. Et tout code binaire ne correspond pas à une lettre. Voilà pourquoi la commande file différencie les fichiers binaires des fichiers texte.

Pourquoi la réduire à du seul texte ?

Car c'est la description dans l'aide.

[chrtophe]

et qui utilise ls dans un script ?!

Tout le monde, sauf ceux que tu as gaulé

Ca fait boum ?

ça ne fera pas boom, car les processus ont des limitations en terme d'usage des ressources, plus ou moins contrôlable avec ulimit.

[Sve@r]

La norme POSIX dit qu'une ligne valide finit par \n. Et tout code binaire ne correspond pas à une lettre. Voilà pourquoi la commande file différencie les fichiers binaires des fichiers texte.

Je ne te parle pas de ligne ou de lettres mais de l'OS (et son système de fichiers) qui, lui, ne fait aucune différence entre "data + \n" et "data".
Et la commande file ne différencie rien, elle "décrit" juste les fichiers qu'on lui donne, se basant pour ça sur le "magic number" éventuel ou une heuristique statistiques. Et cette description n'est faite que pour les humains qui, eux, peuvent avoir besoin de savoir ce qu'ils manipulent.
Quant à la norme POSIX, elle est faite pour ceux qui veulent créer des fichiers qui devront être vus (par d'autres humains) comme des fichiers texte. Ou qui veulent créer des programmes qui devront traiter des fichiers textes.

En voilà une belle bêtise.

Oui c'est vrai, effectivement depuis une mise à jour (qui semble être la 4.3), la substitution refuse maintenant de récupérer de la data qui n'est pas texte (plus exactement elle vire les '\0' éventuels).
Ce qui ne change pas vraiment le fond du problème qui était quand-même "est-ce que récupérer un fichier (ok texte) de 50Go est possible dans une variable" et où répondre "cette commande est inadéquate" était tout sauf pertinente