Tu devrais déplacer ton problème dans le bon forum et surtout nous expliquer comment tu exécutes ton fichier:
Est-ce aussi le cas sous LINUX, ou est-ce un problème typique MacOS ?
Tu devrais déplacer ton problème dans le bon forum et surtout nous expliquer comment tu exécutes ton fichier:
Est-ce aussi le cas sous LINUX, ou est-ce un problème typique MacOS ?
Tu as raison...
Serait il possible à un admin qui passerait par là de déplacer ce fil de discussion dans le forum "Shell d'OS X"
Par ailleurs, je lance le script via le terminal via la commande :
Le script ne fonctionne actuellmement pas sous Linux. Il y a des adaptation à faire... Je n'ai pas creusé lesquelles...
Code : Sélectionner tout - Visualiser dans une fenêtre à part sh monSuperScriptQuiFonctionneEnfin
Pour rappel, et pour ne pas relire l'ensemble du sujet pour savoir de quoi il retourne :
Cela fonctionne lorsqu'il est lancé dans le terminal, et ne fonctionne plus lorsqu'il est dans un fichier.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 ffmpeg -i video.mp4 -f flv out.flv -loglevel quiet -stats 2>&1 | while read -d "$(echo -en '\015')" || [ -n "$REPLY" ] do echo ${REPLY} | sed -n '/frame=/s/frame=[^0-9]*\([0-9]*\).*/\1/p' done
Je suis sous MacOS 10.9
Tu pourrais commencer par remplacer :
qui n'est pas portable par :
Code : Sélectionner tout - Visualiser dans une fenêtre à part "$(echo -en '\015')"
Code : Sélectionner tout - Visualiser dans une fenêtre à part "$(printf "\r")"
Ok, le printf est mieux que le echo mais le script est du bash et le read -d non plus n'est pas portable.
Parler d'un script bash et lancer le script via sh, c'est presque comme lancer perl pour executer python
Tu mesures donc mon niveau en bash... En fait je ne parviens pas à lancer le script avec simplement ./monscript (même avec le chmod +x ) du coup j'ai rajouté sh devant. Sans trop me poser de question j'avoue.
Je crois ne pas bien faire la différence entre les 2, d'autant que si j'ai bien compris, ya tout de même pas mal de choses qui sont valables des 2 cotés...
Toujours est-il que si vous avez de bons conseils à ce propos et/ou de bonne lecture, je suis preneur :-) car je trouve que ces langages permettent des choses tout à fait agréable et utile.
Pour en revenir à la solution proposé :Et bien ça fonctionne... donc merci à vous tous.
Code : Sélectionner tout - Visualiser dans une fenêtre à part "$(printf '\r')"
Hmmm, je ne savais pas que echo -en '\015' en bash dans un terminal et dans un script bash n'avait pas le même comportement.
Si quelqu'un a une explication, je suis preneur.
Je n'ai pas d'explication rationnelle, en dehors du fait que j'évite les "echo -n" et "-e" depuis que j'utilise "printf" en shell.
Il me faudrait un mac pour comprendre ce qui se passe et quel shell est réellement appelé, mais je n'ai pas ça sous la main ...
Sur OS X, c'est Bash qui est utilisé depuis 10.3, avant c'était tcsh. Je ne sais pas si ça n'a pas changé depuis.
Mac OS X est basé sur BSD.
Il y a effectivement des variantes sur les outils de ligne de commande.
Concernant les outils tels que grep ou awk je ne sais pas si il y a des différences, je fais pas assez de ligne de commande.
Voici la doc grep pour mac OS X 10.9 :
https://developer.apple.com/library/...n1/grep.1.html
Les pros de grep pourront voir si c'est identique au grep Linux.
Concernant grep et awk, ce sont les implémentations d'origine Unix de BSD donc il y a de grosses différences avec GNU mais la question en suspens porte sur echo.
"echo" est normalement une builtin de bash mais elle existe aussi en tant que commande en ligne. Cette dernière ne connais pas "-e" et c'est probablement pour ça que le script n'a pas fonctionné. Pourquoi il a appelé le binaire echo au lieu de la builtin est mystérieux, à moins que bash ne change le comportement de la builtin en fonction de l'environnement, de la manière dont il est appelé (bash ou sh) ou quelque chose comme ça.
POSIX recommande d'éviter d'utiliser echo et de prendre printf.
Je pense qu'il y a eu erreur de manipulation: dans le post #22, il dit que le script ne fonctionne pas sous linux.
Et effectivement, celui-ci ne fonctionne pas sous linux si on l'appelle via sh (non lié à bash), mais si on l'appelle via bash, celui-ci fonctionne.
Pour moi, il a modifié le echo en printf mais il a ensuite lancé celui-ci via bash et non sh car sinon, il aurait aussi rencontré un problème avec read -d (pour rappel, mon incompréhension est pourquoi le read -d est passant mais pas le echo -e.
Bon, après je viens de voir un cas à part sur linux:
Le man de ksh (pdksh) dit que l'option -d pour read est supporté mais pas l'option -e de echo, je me positionne en ksh, je tests et résultat:
J'obtiens le résultat inverse...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 # echo -e '\tfoobar' foobar # read -d ':' ksh: read: -d: unknown option
Dans le doute, je regarde le ksh et je vois que celui-ci n'est pas le pdksh mais mksh (MirBSD Korn Shell) et quand je regarde son man, on est bien sur le résultat obtenu.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager