Solution

$ echo 'echo Bonjour !' | sh
Bonjour !
$ sh -c 'echo Bonjour !'
Bonjour !
$ echo 'echo Bonjour !' > commandes
$ sh commandes
Bonjour !

Solution

$ if [ x = x ] then echo oui fi
>

Le shell a lu la commande suivant if jusqu'à l'indication de sa fin, qui est ici la fin de ligne. La commande [ sera donc lancé avec les 8 mots suivants comme paramètres. Le shell étant maintenant un then, suite obligatoire du if.

$ if [ x = x ] then echo oui; fi
bash: syntax error near unexpected token `fi'

Comme précédemment, le shell a lu la commande suivant if jusqu'à l'indication de sa fin, qui est ici le ;. Il attend ensuite un if mais y trouve un fi inattendu.

$ if [ x = x ]; then echo oui fi
>

Il y a du progrès. La commande passée à if est correctement délimitée. Le shell trouve son then, qui peut être suivi d'autant de commandes qu'on le souhaite, jusqu'à rencontrer un elif ou un fi. Ici le fi fait visiblement partie des argument de echo, donc le shell attend d'autres commandes.

$ if [ x = x ]; then echo oui; fi
oui
$ if [ x = x ]; then echo "c'est compris ?"; fi
c'est compris ?

Deux constructions if/then/fi complètes.

Solution

$ man test

Les commandes [ et test sont synonymes, à ceci près que la première voudra un ] en dernier argument. Ainsi [ "$x" = on ] peut tout aussi bien s'écrire test "$x" = on.

Solution

$ if grep 9 primes; then echo oui; fi
19
29
oui

En pratique on utilisera plus volontiers if grep -q 9 primes; then afin de supprimer l'affichage de grep.

Solution

Voici trois solutions pour chaque phrase. La première basée sur '...', la seconde sur "..." et la troisième n'utilisant ni l'un ni l'autre.

echo 'Est-ce que 3 * 5 = 15 ?'
echo "Est-ce que 3 * 5 = 15 ?"
echo Est-ce que 3 \* 5 = 15 \?

echo 'Je m'\''appelle "Alexandre"'
echo "Je m'appelle \"Alexandre\""
echo Je m\'appelle \"Alexandre\"

echo 'Je n'\''ai que $3 en banque.'
echo "Je n'ai que \$3 en banque."
echo Je n\'ai que \$3 en banque.

echo '#include <stdio.h>'
echo "#include <stdio.h>"
echo \#include \<stdio.h\>

echo 'prog:10: option `foobar'\'' inconnue'
echo "prog:10: option \`foobar' inconnue"
echo prog:10: option \`foobar\' inconnue

Solution

Il n'y en a pas. Les appostrophe ne servent qu'a empêcher le shell de couper l'argument en deux sur l'espace : leur position n'est pas importante tant qu'elles encadrent l'espace.

Solution

Les problèmes découlent de l'emploi de ; au sein de l'alias, et surviennent lorsqu'on combine cd a une autre commande avec && ou ||. Par exemple

$ [ -d dir ] && cd dir
cd: no such file or directory: dir

En effet après substitution de l'alias, la commande ci-dessus s'est transformée ainsi

$ [ -d dir ] && t=$((t + 1)); cd dir

Le && ne porte sur l'affectation et non le cd qui suit.

Le premier réflexe est d'essayer de changer ; en && ou ||, mais cela n'aide pas lorsqu'on combine cd avec l'autre opérateur. De façon générale, la substitution d'alias n'est pas l'outil idéal pour remplacer une commande par plusieurs. On fera mieux d'utiliser une fonction.

Solution

Le piège de l'appel récursif à cd est évité avec la commande builtin [non-standard] qui demande au shell d'utiliser sa définition interne pour la commande qui suit

$ cd() { $((t + 1)); builtin cd "$@"; }

Solution

Voici l'évolution des descripteurs de fichiers au fur et à mesure que les opérateurs sont pris en compte.

cmd1... | tac

cmd1... 2>&1 | tac

cmd1... 2>&1 >out | tac

cmd1... 2>&1 >out | tac >err

Autrement dit la sortie standard de cmd1... est envoyée dans out, tandis que sa sortie d'erreur est retournée par tac puis envoyée dans err.

Solution

#!/bin/sh
exec 3>&1
"$@" 2>&1 1>&3 | grep --color . 1>&2

Solution

L'utilisateur ajoute la ligne

PATH=$HOME/usr/bin:$PATH

dans l'un des fichiers ~/.bash_profile, ~/.bash_login, ou ~/.profile, selon ce qu'il utilise.

Il est normalement inutile faire cette modification dans ~/.bashrc puisque les autres shells lancés depuis le shell de login hériteront de cette variable d'environnement.

Solution

La commande

alias ls='ls -v -F -b -T 0 --color=auto'

devrait être ajoutée à ~/.bash_profile, ~/.bash_login, ou ~/.profile (selon ce qui est déjà utilisé) pour les shells de login, mais aussi dans .bashrc pour les autres shells.

Devoir maintenir deux configurations est assez pénible. Bien souvent, on ajoutera le ligne suivante à la fin de ~/.bash_profile (ou ~/.bash_login ou ~/.profile...)

[ -f ~/.bashrc ] && . ~/.bashrc

afin que ~/.bashrc soit aussi exécuté par les shells de logins.

Le fichier ~/.bash_profile (ou...) est alors utilisé pour définir les variables d'environnements, et ~/.bashrc pour le reste (définitions d'alias et de fonctions principalement).

Solution

Les shells non interactifs sont utilisés par tous les script shells que l'on peut lancer. On ne souhaite pas que leur configuration diffère d'un utilisateur à l'autre. Par exemple si un utilisateur a définit un alias sur cd, celui-ci ne doit pas influencer un script qui croit appeler le vrai cd.

La situation peut être encore pire si le fichier de configuration donne une valeur fixe à une variable d'environnement telle que PATH, car de nombreux scripts modifient cette variable pour lancer d'autres scripts et échoueront si modification de la variable est annulée dans chaque sous-shell.

Solution

PS1='\! \w $'

Solution

$ mv !!:2 !!:1

Solution

$ !!:gs/text/test/

Solution

$ sh -x /usr/bin/ldd 2>&1 | grep '+ echo ' | wc -l
2

Solution

set -e
com1
com2
com3
com4

Ou bien sûr

com1 &&
com2 &&
com3 &&
com4

Solution

Ces scripts sont exécutés par des shells non-interactifs. Ces shells exécutent donc n'importe quel fichier indiqué par $BASH_ENV avant d'exécuter le script lui-même.

$ echo 'set -x' > set-x
$ BASH_ENV=$PWD/set-x
$ export BASH_ENV
$ ldd
+ TEXTDOMAIN=libc
+ TEXTDOMAINDIR=/usr/share/locale
+ RTLDLIST='/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2'
+ warn=
+ bind_now=
+ verbose=
+ filename_magic_regex='((^|/)lib|.so$)'
+ test 0 -gt 0
+ add_env='LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW='
+ add_env='LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out'
+ add_env='LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE='
+ test '' = yes
+ set -o pipefail
+ case $# in
+ echo ldd: 'missing file arguments'
ldd: missing file arguments
+ echo 'Try `ldd --help'\'' for more information.'
Try `ldd --help' for more information.
+ exit 1

Solution

#! /bin/sed -nf
1!G;$p;h

Ce script se comporte comme la commande tac : il écrit son entrée standard (ou les fichiers qu'on lui indique) lignes par lignes mais à l'envers.

Solution

stathist() {
  history |
  awk '{ print $2 }' |
  sort |
  uniq -c |
  sort -rn |
  head -n 5
}

Cette fonction fait référence à des propriété du shell courant (l'historique) auquel un script externe n'aurait pas accès.

Il est possible de configurer bash pour que plusieurs instances partagent leur historique, mais de toute façon l'historique n'est pas active dans les shells non-intéractifs.

Solution

#!/bin/sh

exec 3< $1 4< $2

while true; do
  read ligne3 <&3
  c=$?
  read ligne4 <&4
  c=$c$?
  [ "$c" = 11 ] && break
  echo "$ligne3     $ligne4"
done

Solution

#!/bin/sh
n=3
for i in "$@"; do
  eval "exec $n< $i"
  # La variable $r contient bout à bout tous les blocs
  # d'instructions du style
  #   read ligne3 <&3
  #   c=$c$?
  #   read ligne4 <&4
  #   c=$c$?
  #   ...
  r="${r}read ligne$n <&$n; c=\$c\$?;"
  # construit une chaîne de n `1'.
  uns=1$uns
  # La variable $e contient la commande d'affichage, de la forme
  #   echo "$ligne3""       $ligne4""       $ligne5"...
  if [ -z "$e" ]; then
    e="echo \"\$ligne$n\""
  else
    e=$e"\" \$ligne$n\""
  fi
  n=$((n + 1))
done

while true; do
  c=
  eval "$r"
  [ "$c" = "$uns" ] && break
  eval "$e"
done