Les petites infos – 7

Rentrée difficile here, on va reprendre doucement avec des petites infos.

Comment obtenir la taille d’un fichier dans un script bash

Je n’avais jamais eu à récupérer la taille d’un fichier dans un script bash, j’en ai eu besoin pour un script perso. Sans trop réfléchir, je me dis du --human-readable /data/file, je vois 31G alors que j’attendais 30G. Je découvre l’option --apparent-size : print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like et vous fais une piqûre de rappel man du : du - estimate file space usage.

du --apparent-size --human-readable /data/file me donne bien 30G mais je fais une recherche pour connaître la meilleure pratique. Ici j’apprends que le plus « reliable » (fiable) est stat --printf="%s" /data/file et accessoirement qu’entre stat, wc, du, la première commande fait le moins d’appels système (system calls).

I/O redirection summary for bash and POSIX shell

Un magnifique tableau trouvé chez nixCraft, bien utile, très clair.

/usr/bin/bash ou /usr/bin/env bash dans un script bash

J’ai noté que tout le monde était passé sur #!/usr/bin/env bash. Comme j’aime bien comprendre les choses, je n’avais pas effectué la modification de mes scripts persos, j’ai pris le temps de faire une recherche et comprendre le pourquoi. On fait le tour de la question avec ces liens (1, 2). J’utilise maintenant #!/usr/bin/env bash.

Ce qui m’a le plus intéressé personnellement (il y a d’autres subtilités, allez lire les liens).

#!/usr/bin/env bash # lends you some flexibility on different systems
#!/usr/bin/bash     # gives you explicit control on a given system of what executable is called

« In some situations, the first may be preferred (like running python scripts with multiple versions of python, without having to rework the executable line). But in situations where security is the focus, the latter would be preferred, as it limits code injection possibilities ».

Simuler l’environnement avec lequel cron exécute un script

Je détecte un problème sur un cron lançant un script. Le script me paraît bon, je lance à la main, il passe. Je pige pas tout de suite puis je pense à l’env, je le simule.

* * * * * root env > ~/cronenv # Dans un cron
env - $(<~/cronenv) /bin/sh /home/monjoliscript.sh # Lancé manuellement

Une commande du script n’était pas dans le PATH, un classique, il a suffi de renseigner le chemin complet/absolu de la commande pour résoudre le souci.

flysystem

Sur le Jdh on commence à avoir des ESN (entreprise de services du numérique, anciennement SSII) qui viennent poster leurs articles de blog, évidemment ça parle de libre sinon ça serait immédiatement supprimé par votre serviteur. Je reste très attentif à ce qu’ils font, pour ne pas dire que je les marque à la culotte. Avec un titre comme Importer des ressources depuis Microsoft Sharepoint dans le PIM Akeneo, je m’attendais au mieux à ce que l’article fasse un bide, au pire à devoir le supprimer voire à ce qu’un utilisateur n’ayant pas lu l’article se plaigne qu’il soit sur le Jdh.

Dans mon rôle de modérateur, je lis l’article et je découvre flysystem : « Flysystem is a filesystem abstraction library for PHP. By providing a unified interface for many different filesystems you’re able to swap out filesystems without application wide rewrites. Using Flysystem can eliminate vendor-lock in, reduce technical debt, and improve the testability of your code ».

J’ai plussé l’info sur le Jdh, elle est restée à 2 votes car le titre est très mal choisi pour le public du Jdh. Un utilisateur normal, je lui aurais envoyé un mail pour lui en faire part, je me voyais mal informer l’ESN que son titre est mauvais sur son blog d’entreprise. Cependant au regard de l’intérêt de flysystem, l’article est pertinent pour le prendre en main.