Script Bash ne continue pas à lire la ligne suivante du fichier
J'ai un script shell qui enregistre la sortie d'une commande qui est exécutée dans un fichier CSV. Il lit la commande qu'il a à exécuter à partir d'un script shell qui est dans ce format:
ffmpeg -i /home/test/videos/avi/418kb.avi /home/test/videos/done/418kb.flv
ffmpeg -i /home/test/videos/avi/1253kb.avi /home/test/videos/done/1253kb.flv
ffmpeg -i /home/test/videos/avi/2093kb.avi /home/test/videos/done/2093kb.flv
Vous pouvez voir chaque ligne de commande ffmpeg. Cependant, le script ne s'exécute la première ligne. Seulement il y a une minute, il faisait près de toutes les commandes. Il manquait la moitié pour une raison quelconque. J'ai édité le fichier texte contenant les commandes et maintenant elle ne peut le faire la première ligne. Voici mon script bash:
#!/bin/bash
# Shell script utility to read a file line line.
# Once line is read it will run processLine() function
#Function processLine
processLine(){
line="$@"
START=$(date +%s.%N)
eval $line > /dev/null 2>&1
END=$(date +%s.%N)
DIFF=$(echo "$END - $START" | bc)
echo "$line, $START, $END, $DIFF" >> file.csv 2>&1
echo "It took $DIFF seconds"
echo $line
}
# Store file name
FILE=""
# get file name as command line argument
# Else read it from standard input device
if [ "$1" == "" ]; then
FILE="/dev/stdin"
else
FILE="$1"
# make sure file exist and readable
if [ ! -f $FILE ]; then
echo "$FILE : does not exists"
exit 1
elif [ ! -r $FILE ]; then
echo "$FILE: can not read"
exit 2
fi
fi
# read $FILE using the file descriptors
# Set loop separator to end of line
BAKIFS=$IFS
IFS=$(echo -en "\n\b")
exec 3<&0
exec 0<$FILE
while read line
do
# use $line variable to process line in processLine() function
processLine $line
done
exec 0<&3
# restore $IFS which was used to determine what the field separators are
BAKIFS=$ORIGIFS
exit 0
Merci pour toute aide.
Mise à JOUR 2
Son le ffmpeg commandes plutôt que le shell script qui ne fonctionne pas. Mais je dois d'été en utilisant simplement "\b", comme Paul l'a souligné. Je suis également faire usage de Johannes plus courte du script.
J'ai juste essayé "\n" et toujours il ne lit que la première ligne. Je ne suis pas très bon dans les scripts shell.
Et mettre un peu d'échos dans processLine pour voir ce qui se passait et quand c'est fait, le traitement. C'est peut-être ffmpeg qui n'est pas de retour.
Je pense que vous avez raison. Je vais vérifier ce que ffmpeg est fait manuellement par l'exécution de quelques commandes.
Maintenant, vous savez pourquoi vous mettez des trucs sous CM de contrôle immédiatement, de sorte que vous pouvez revenir à des versions de travail!
OriginalL'auteur Abs | 2009-02-17
Vous devez vous connecter pour publier un commentaire.
Je pense que cela devrait faire de même et semble être correct:
pas?
Je l'ai testé avec les différentes commandes et il fonctionne. Peut-être ffmpeg ne fonctionne que TRÈS longtemps?
Fait-il l'écho de la "Il a pris ..." après le dernier ffmpeg? C'est peut-être pas terminer aussi vite que vous pensez qu'il devrait?
En fonction de la conversion, ffmpeg peut être très longue. Vous pouvez obtenir un état d'avancement par pas de filtrage de sortie d'erreur standard.
Oui, FFmpeg ne prendre un certain temps, dans certains cas, mais ne pas le script shell attendre jusqu'à ce que la commande est terminée??
OriginalL'auteur Johannes Weiss
ffmpeg lit l'entrée standard STDIN et l'expulse. La solution est d'appeler ffmpeg avec:
Voir l'explication détaillée ici: http://mywiki.wooledge.org/BashFAQ/089
OriginalL'auteur mivk
J'ai juste eu le même problème.
Je crois que ffmpeg est responsable de ce comportement.
Ma solution pour ce problème:
1) Appel ffmpeg avec un "&" à la fin de votre ffmpeg en ligne de commande
2) Depuis maintenant le skript ne va pas attendre jusqu'à la fin de l'ffmpeg processus,
nous avons pour prévenir de notre script de démarrage de plusieurs ffmpeg processus.
Nous atteindrons cet objectif en retardant la boucle de passe tout y est au moins
une course ffmpeg processus.
OriginalL'auteur KPMueller
Je voudrais ajouter echos avant et après l'eval pour voir de quoi il s'agit à la fonction eval (en cas de traitement de l'ensemble du fichier en une longue ligne) et après (dans le cas où l'un des ffmpeg commandes est de prendre une éternité).
OriginalL'auteur Paul Tomblin
Sauf si vous prévoyez de lire quelque chose à partir de l'entrée standard après la boucle, vous n'avez pas besoin de conserver et de restaurer l'original de l'entrée standard (si c'est bien de voir que vous savez comment).
De la même façon, je ne vois pas une raison pour dinking avec les FI. Il n'y a certainement pas besoin de restaurer la valeur de FI avant la sortie - c'est un vrai shell que vous utilisez, pas un DOS fichier BAT.
Lorsque vous faites:
la coquille attribue le premier champ de
$var1
, la deuxième à$var2
, et le reste de la ligne$var3
. Dans le cas où il y a une variable de votre script, par exemple - l'ensemble de la ligne va dans la variable, tout comme vous le souhaitez.À l'intérieur du processus de la ligne de fonction, vous avez sans doute ne voulez pas de jeter la sortie d'erreur de la commande exécutée. Vous n'avez probablement envie de penser à la vérification de l'état de sortie de la commande. Le
echo
avec l'erreur de redirection est ... inhabituel, et overkill. Si vous êtes assez sûr que les commandes ne pouvez pas échouer, puis aller de l'avant avec d'ignorer l'erreur. Est la commande 'bavard'; si, donc, de jeter le chat par tous les moyens. Si non, peut-être que vous n'avez pas besoin de jeter de sortie standard, soit.Le script dans son ensemble devrait probablement diagnostiquer quand il est donné de multiples fichiers à traiter, car il ignore ce qui est superflu.
Vous pouvez simplifier votre gestion des fichiers en utilisant seulement:
La
cat
commande automatiquement les rapports d'erreurs (et continue après eux) et les processus de tous les fichiers d'entrée, ou lit l'entrée standard si il n'y a pas d'arguments à gauche. L'utilisation de guillemets autour de la variable signifie qu'il est passé comme une seule unité (et donc unparsed en mots distincts).L'utilisation de
date
etbc
est intéressant - je n'avais pas vu ça avant.Dans l'ensemble, je serais à la recherche de quelque chose comme:
OriginalL'auteur Jonathan Leffler