Variable versus fichier temporaire

Version imprimable

26/09/2023, 17h37
NeoType

Variable versus fichier temporaire
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:

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:

1 2 resultat=$(cat video_de_50Go.avi)
Ca fait boum ? ^^

(Tu me diras que je n'ai qu'à tester pour voir...)
26/09/2023, 18h49
N_BaH

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

et qui utilise ls dans un script ?! :massacre:
:mouarf:
26/09/2023, 19h04
Flodelarab

Bonjour :coucou:

Citation:

Envoyé par N_BaH

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

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.

Citation:

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.
26/09/2023, 19h33
Sve@r

Bonjour

Citation:

Envoyé par NeoType

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)".

Citation:

Envoyé par NeoType

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)

Citation:

Envoyé par NeoType

Par contre quid de la commande suivante:

Code:

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).

Citation:

Envoyé par Flodelarab

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".
26/09/2023, 20h06
Flodelarab

Citation:

Envoyé par Sve@r

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.

Citation:

Pourquoi la réduire à du seul texte ?

Car c'est la description dans l'aide.
26/09/2023, 20h41
Christophe

Citation:

et qui utilise ls dans un script ?!

Tout le monde, sauf ceux que tu as gaulé :)

Citation:

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.
26/09/2023, 21h40
Sve@r

Citation:

Envoyé par Flodelarab

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.

Citation:

Envoyé par Flodelarab

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 :roll: