Les deux commandes suivantes tentent d'ouvrir un fichier inexistant foo, mais les messages d'erreur sont un peu différents. Quelle pourrait être la raison?
$ cat foo
cat: cannot open foo
$ cat < foo
-bash: foo: No such file or directory
command-line
io-redirection
cat
Zain Rafi
la source
la source
cat < foodau lieu decat < foofood < cat)cat. Maintenant, je me demande d'où vient le deuxième message, étant donné qu'il commence parbash:...Réponses:
Cela exécute la
catcommande avec argumentfoo. L'erreur imprimée à l'écran dépend entièrement de ce qui a été décidé par le programmeur de la commande.Cela alimente le contenu du fichier
fooà lacatcommande en utilisant la redirection Bash stdin . Si le fichier n'existe pas, c'est Bash qui s'en plaint.la source
Dans
$ cat foole shell (ici bash) exécute lacatcommande et passe le paramètrefoo. Le programme cat choisit d'interpréter ce paramètre comme un nom de fichier - et essaie d'ouvrir le fichier. L'erreur que vous voyez provient du programme cat qui (naturellement) ne peut pas ouvrir le fichier.La version
$ cat < fooest une redirection gérée par le shell.<est un opérateur shell qui demande au shell d'ouvrir un fichier et de le rediriger vers stdin. Le fichier n'existe pas, vous obtenez donc "Aucun fichier de ce type". Cette fois, l'erreur vient du shell (bash) et semble un peu différente.C'est pourquoi vous voyez 2 erreurs différentes. La cause est la même - mais elle provient de 2 programmes différents (cat et bash).
la source
cat < foo,catn'est pas appelé si la redirection échoue. Cela (et avoir un message d'erreur cohérent) est l'une des raisons pour lesquelles il est souvent préférable d'utiliser la redirection dans la mesure du possible. Considérez également lecat < in > outvscat in > outoù le premier empêcheoutd'être écrasé s'ilinn'existe pas (le shell annule la commande juste après l'échec de la< inredirection et ne fait pas la> outredirection suivante , encore moins l'invoquercat).