Bash : écrire 2 types de données ds un fichier
Résolu/Fermé
arscy
Messages postés
173
Date d'inscription
dimanche 26 janvier 2014
Statut
Membre
Dernière intervention
5 octobre 2023
-
12 févr. 2023 à 11:01
jee pee Messages postés 39695 Date d'inscription mercredi 2 mai 2007 Statut Modérateur Dernière intervention 5 mai 2024 - 12 févr. 2023 à 15:29
jee pee Messages postés 39695 Date d'inscription mercredi 2 mai 2007 Statut Modérateur Dernière intervention 5 mai 2024 - 12 févr. 2023 à 15:29
A voir également:
- Bash : écrire 2 types de données ds un fichier
- Retour à la ligne bash ✓ - Forum Shell
- Bash path - Astuces et Solutions
- Bash permission non accordée - Forum Shell
- Bingo bash free - Télécharger - Divers Jeux
- Bash arguments - Astuces et Solutions
1 réponse
jee pee
Messages postés
39695
Date d'inscription
mercredi 2 mai 2007
Statut
Modérateur
Dernière intervention
5 mai 2024
9 258
Modifié le 12 févr. 2023 à 13:33
Modifié le 12 févr. 2023 à 13:33
Bonjour,
Je ne vois pas ce que tu veux faire ni à quoi correspond CALCUL. Cette syntaxe signifie que le stdin pour monapplication est pris dans le script lui même, toutes les lignes jusqu'au label de fin CALCUL.
La ligne end=... ne va pas être exécutée par le shell, puisque considérée comme donnée à fournir au programme en cours d'exécution, et pas utilisée, puisque l'on peut supposer que monapplication ne requiert pas d'input.
Sur le fond de ton problème, moi je dirais que le temps d'affichage sur la console est supérieur à l'enregistrement des lignes dans un fichier. Et si tu veux un temps d'exécution pur, il faudrait que le programme ne fasse pas d'écritures en sortie.
Tu pourrais tout simplement faire :
start=$(date +%s%N) ./monapplication >fichierDeDestination end=$(date +%s%N) echo Temps $start $end $((end-start)) >> fichierDeDestination
12 févr. 2023 à 15:19
Bonjour jee pee,
J'ai assez vite compris en effet que l'écriture de ma dernière version ne faisait pas grand sens (sinon que celui d'essayer de manipuler des variables à un endroit où je n'ai pas le droit de le faire visiblement.
Après réflexion, ta suggestion -- que je ne souhaitais pas mettre en place -- est applicable dans mon cas de figure.
Donc je prendrai en tant que tel.
Pour la notion d'exécution pure, malheureusement le programme exécuté n'est pas de mon ressort, mais je te rejoins là dessus. Je le considérerai comme un biais de temps de calcul (maximisé).
Merci !
12 févr. 2023 à 15:29
tu pourrais évaluer 3 situations, le temps d’exécution avec un fichier de sortie, le temps d’exécution à l’écran, et le temps d'exécution avec un >/dev/null