ATOM 9 H 1 -4.502 0.681 0.785 1.00 0.00ATOM 10 H 1 -5.254 -0.243 -0.537 1.00 0.00ATOM 11 H 1 -4.357 1.252 -0.895 1.00 0.00ATOM 12 H 1 -3.009 -0.741 -1.467 1.00 0.00ATOM 13 H 1 -3.172 -1.337 0.206 1.00 0.00

$ nano middle.sh

head -n 15 "" | tail -n 5

$ bash middle.sh octane.pdb

ATOM 9 H 1 -4.502 0.681 0.785 1.00 0.00ATOM 10 H 1 -5.254 -0.243 -0.537 1.00 0.00ATOM 11 H 1 -4.357 1.252 -0.895 1.00 0.00ATOM 12 H 1 -3.009 -0.741 -1.467 1.00 0.00ATOM 13 H 1 -3.172 -1.337 0.206 1.00 0.00

$ bash middle.sh pentane.pdb

# Sort files by their length.# Usage: bash sorted.sh one_or_more_filenameswc -l "$@" | sort -n

$ bash sorted.sh *.pdb ../creatures/*.dat

9 methane.pdb12 ethane.pdb15 propane.pdb20 cubane.pdb21 pentane.pdb30 octane.pdb163 ../creatures/basilisk.dat163 ../creatures/minotaur.dat163 ../creatures/unicorn.dat596 total

Liste des espèces uniques

Leah possède plusieurs centaines de fichiers de données, chacun étant formaté de la manière suivante :

2013-11-05,deer,52013-11-05,rabbit,222013-11-05,raccoon,72013-11-06,rabbit,192013-11-06,deer,22013-11-06,fox,12013-11-07,rabbit,182013-11-07,bear,1

Un exemple de ce type de fichier est donné dans data-shell/data/animal-counts/animals.txt.

Nous pouvons utiliser la commande cut -d , -f 2 animals.txt | sort | uniq pour produire l’espèce unique dans animals.txt. Afin d’éviter d’avoir à taper cette série de commandes à chaque fois, un scientifique peut choisir d’écrire un script shell à la place.

Écrivez un script shell appelé species.sh qui prend un nombre quelconque de noms de fichiers comme arguments de ligne de commande, et utilise une variation de la commande ci-dessus pour imprimer une liste des espèces uniques apparaissant dans chacun de ces fichiers séparément.

Solution

# Script to find unique species in csv files where species is the second data field# This script accepts any number of file names as command line arguments# Loop over all filesfor file in $@doecho "Unique species in $file:"# Extract species namescut -d , -f 2 $file | sort | uniqdone

Supposons que nous venons d’exécuter une série de commandes qui ont fait quelque chose d’utile – par exemple, qui ont créé un graphique que nous aimerions utiliser dans un article.Nous aimerions pouvoir recréer le graphique plus tard si nous en avons besoin, donc nous voulons enregistrer les commandes dans un fichier.Au lieu de les taper à nouveau (et potentiellement de se tromper), nous pouvons faire ceci :

$ history | tail -n 5 > redo-figure-3.sh

Le fichier redo-figure-3.sh contient maintenant :

297 bash goostats NENE01729B.txt stats-NENE01729B.txt298 bash goodiff stats-NENE01729B.txt /data/validated/01729.txt > 01729-differences.txt299 cut -d ',' -f 2-3 01729-differences.txt > 01729-time-series.txt300 ygraph --format scatter --color bw --borders none 01729-time-series.txt figure-3.png301 history | tail -n 5 > redo-figure-3.sh

Après un moment de travail dans un éditeur pour enlever les numéros de série sur les commandes, et pour enlever la dernière ligne où nous avons appelé la commande history, nous avons un enregistrement complètement précis de la façon dont nous avons créé cette figure.

Pourquoi enregistrer les commandes dans l’historique avant de les exécuter ?

Si vous exécutez la commande :

$ history | tail -n 5 > recent.sh

la dernière commande du fichier est la commande history elle-même, c’est à dire ,le shell a ajouté history au journal des commandes avant de l’exécuter réellement. En fait, le shell ajoute toujours les commandes au journal avant de les exécuter. Pourquoi pensez-vous qu’il fait cela ?

Solution

Si une commande provoque un crash ou un blocage, il pourrait être utile de savoir quelle était cette commande, afin d’enquêter sur le problème.Si la commande n’était enregistrée qu’après son exécution, nous n’aurions pas d’enregistrement de la dernière commande exécutée en cas de crash.

En pratique, la plupart des gens développent des scripts shell en exécutant des commandes à l’invite du shell quelques fois pour s’assurer qu’ils font la bonne chose,puis en les enregistrant dans un fichier pour les réutiliser.Ce style de travail permet aux gens de recycler ce qu’ils découvrent sur leurs données et leur flux de travail avec un appel à historyet un peu d’édition pour nettoyer la sortie et l’enregistrer comme un script shell.

Nelle’s Pipeline : Création d’un script

Le superviseur de Nelle a insisté pour que toutes ses analyses soient reproductibles. La façon la plus simple de capturer toutes les étapes est dans un script.

Premièrement, nous retournons dans le répertoire de données de Nelle:

$ cd ../north-pacific-gyre/2012-07-03/

Elle lance l’éditeur et écrit ce qui suit:

# Calculate stats for data files.for datafile in "$@"do echo $datafile bash goostats $datafile stats-$datafiledone

Elle enregistre cela dans un fichier appelé do-stats.shde sorte qu’elle peut maintenant refaire la première étape de son analyse en tapant :

$ bash do-stats.sh NENE*.txt

Elle peut aussi faire ceci:

$ bash do-stats.sh NENE*.txt | wc -l

pour que la sortie soit juste le nombre de fichiers traités plutôt que les noms des fichiers qui ont été traités.

Une chose à noter à propos du script de Nelle est qu’il laisse la personne qui l’exécute décider des fichiers à traiter.Elle aurait pu l’écrire comme suit :

# Calculate stats for Site A and Site B data files.for datafile in NENE*.txtdo echo $datafile bash goostats $datafile stats-$datafiledone

L’avantage est que cela sélectionne toujours les bons fichiers : elle n’a pas besoin de se rappeler d’exclure les fichiers ‘Z’. L’inconvénient est que cela ne sélectionne toujours que ces fichiers – elle ne peut pas l’exécuter sur tous les fichiers (y compris les fichiers ‘Z’), ou sur les fichiers ‘G’ ou ‘H’ que ses collègues en Antarctique produisent, sans modifier le script.Si elle voulait être plus aventureuse, elle pourrait modifier son script pour vérifier les arguments de la ligne de commande, et utiliser NENE*.txt si aucun n’a été fourni.Bien sûr, cela introduit un autre compromis entre flexibilité et complexité.

Variables dans les scripts shell

Dans le répertoire molecules, imaginez que vous avez un script shell appelé script.sh contenant les commandes suivantes :

head -n  tail -n  

Alors que vous êtes dans le répertoire molecules, vous tapez la commande suivante :

bash script.sh '*.pdb' 1 1

Quelle sortie suivante vous attendriez-vous à voir ?

1. Toutes les lignes entre la première et la dernière ligne de chaque fichier se terminant par .pdbdans le répertoire molecules
2. La première et la dernière ligne de chaque fichier se terminant par .pdb dans le molecules répertoire
3. La première et la dernière ligne de chaque fichier dans le répertoire molecules
4. Une erreur à cause des guillemets autour de *.pdb

Solution

La bonne réponse est 2.

Les variables spéciales $1, $2 et $3 représentent les arguments de ligne de commande donnés au script, de sorte que les commandes exécutées sont :

$ head -n 1 cubane.pdb ethane.pdb octane.pdb pentane.pdb propane.pdb$ tail -n 1 cubane.pdb ethane.pdb octane.pdb pentane.pdb propane.pdb

Le shell ne développe pas '*.pdb' parce qu’il est entouré de guillemets.Ainsi, le premier argument du script est '*.pdb' qui est développé dans le script par head et tail.

Trouver le fichier le plus long avec une extension donnée

Écrivez un script shell appelé longest.sh qui prend le nom d’un répertoire et une extension de nom de fichier comme arguments, et imprime le nom du fichier avec le plus de lignes dans ce répertoire avec cette extension. Par exemple:

$ bash longest.sh /tmp/data pdb

imprime le nom du fichier .pdb dans /tmp/data qui a le plus de lignes.

Solution

# Shell script which takes two arguments:# 1. a directory name# 2. a file extension# and prints the name of the file in that directory# with the most lines which matches the file extension.wc -l /*. | sort -n | tail -n 2 | head -n 1

La première partie du pipeline, wc -l /*. | sort -n, compte les lignes dans chaque fichier et les trie numériquement (les plus grandes en dernier). Lorsqu’il y a plus d’un fichier, wc produit également une ligne de résumé final, donnant le nombre total de lignes dans tous les fichiers. Nous utilisons tail-n 2 | head -n 1 pour jeter cette dernière ligne.

Avec wc -l /*. | sort -n | tail -n 1, nous verrons la ligne de résumé final : nous pouvons construire notre pipeline par morceaux pour être sûrs de comprendre la sortie.

Compréhension de lecture de scripts

Pour cette question, considérez à nouveau le répertoire data-shell/molecules.Celui-ci contient un certain nombre de fichiers .pdb en plus de tout autre fichier que vous avez pu créer.Expliquez ce que chacun des trois scripts suivants ferait lorsqu’il est exécuté en tant quebash script1.sh *.pdb, bash script2.sh *.pdb et bash script3.sh *.pdb respectivement.

# Script 1echo *.*

# Script 2for filename in   do cat $filenamedone

# Script 3echo [email protected]

Solutions

Dans chaque cas, l’interpréteur de commandes développe le caractère générique dans *.pdb avant de transmettre la liste résultante de noms de fichiers comme arguments au script.

Le script 1 imprimerait une liste de tous les fichiers contenant un point dans leur nom.Les arguments passés au script ne sont en fait utilisés nulle part dans le script.

Le script 2 imprimerait le contenu des 3 premiers fichiers ayant une extension .pdb., et font référence au premier, deuxième et troisième argument respectivement.

Le script 3 imprimerait tous les arguments du script (c’est-à-dire tous les fichiers .pdb),suivis de .pdb.$@ fait référence à tous les arguments donnés à un script shell.

cubane.pdb ethane.pdb methane.pdb octane.pdb pentane.pdb propane.pdb.pdb

Débogage de scripts

Supposons que vous ayez enregistré le script suivant dans un fichier appelé do-errors.shdans le répertoire north-pacific-gyre/2012-07-03 de Nelle :

# Calculate stats for data files.for datafile in "$@"do echo $datfile bash goostats $datafile stats-$datafiledone

Lorsque vous l’exécutez :

$ bash do-errors.sh NENE*.txt

la sortie est vide.Pour savoir pourquoi, ré-exécutez le script en utilisant l’option -x:

bash -x do-errors.sh NENE*.txt

Que vous montre la sortie ? Quelle ligne est responsable de l’erreur ?

Solution

L’option -x fait tourner bash en mode débogage.Cela imprime chaque commande au fur et à mesure de son exécution, ce qui vous aidera à localiser les erreurs.Dans cet exemple, nous pouvons voir que echo n’imprime rien. Nous avons fait une faute de frappe dans le nom de la variable de boucle, et la variable datfile n’existe pas, renvoyant donc une chaîne vide.

Points clés

• Enregistrer les commandes dans des fichiers (généralement appelés scripts shell) pour les réutiliser.

• bash exécute les commandes enregistrées dans un fichier.

• $@ fait référence à tous les arguments de ligne de commande d’un script shell.

• , , etc, font référence au premier argument de ligne de commande, au deuxième argument de ligne de commande, etc.

• Placez les variables entre guillemets si les valeurs peuvent comporter des espaces.

• Laisser les utilisateurs décider des fichiers à traiter est plus souple et plus cohérent avec les commandes Unix intégrées.