Maison >développement back-end >Tutoriel Python >Tutoriel de base sur la redirection des tuyaux Shell
Le pipeline existe pour résoudre le problème de la communication inter-processus. Il permet de transférer des données entre deux processus, et les données de sortie d'un processus sont transférées à un autre processus en tant que données d'entrée
1.8.1 Tuyau anonyme"|"
Le symbole du tuyau signifie, comme son nom l'indique, qu'il est comme un tuyau, transmettant les données de l'entrée du tuyau à la sortie du tuyau à travers le tuyau.
Le pipeline existe pour résoudre le problème de la communication inter-processus. Il permet de transférer des données entre deux processus, et les données de sortie d'un processus sont transférées à un autre processus en tant que données d'entrée. Le côté gauche du canal est le fournisseur de données et le côté droit du canal est le récepteur de données.
Par exemple, echo "abcd" | passwd --stdin username
signifie que le résultat de sortie "abcd" de l'écho du processus est utilisé comme données d'entrée du mot de passe du processus.
Les symboles de base des tuyaux et leur utilisation sont faciles à comprendre. La question est maintenant, pour ps aux | grep "ssh"
, pourquoi le processus grep apparaît-il dans les résultats ?
[root@xuexi ~]# ps aux | grep ssh root 1211 0.0 0.1 82544 3600 ? Ss Jul26 0:00 /usr/sbin/sshd -D root 25236 0.0 0.2 145552 5524 ? Ss 05:28 0:00 sshd: root@pts/0 root 25720 0.1 0.2 145416 5524 ? Ss 06:15 0:00 sshd: root@pts/1 root 25770 0.0 0.0 112648 948 pts/1 S+ 06:15 0:00 grep --color=auto ssh
Selon l'idée générale, ps est exécuté en premier, et après avoir obtenu la sortie, les données de sortie sont transmises à grep Pour le moment, grep ne l'a pas fait. encore exécuté et ps a fini de fonctionner. Pourquoi pouvons-nous toujours collecter des statistiques sur le processus grep ? La raison en est que le pipeline implémente la communication entre les processus et qu'il y a un chevauchement entre les deux processus. Après l'exécution du processus ps, les informations sur le processus commencent également à être collectées et sont en attente de réception des données. Lorsque ps collecte des données, la sortie est publiée. Les données sont transmises en mémoire et transmises à grep pour le filtrage.
L'essence d'un canal est le transfert de données. Les données de sortie sur le côté gauche du canal sont mises en mémoire et lues par le processus sur le côté droit du canal. Si la mémoire n'est pas suffisante pour stocker complètement les données de sortie, le processus du côté gauche du tube attendra que le côté droit du tube retire une partie des données en mémoire afin que le processus du côté gauche du tube Le tuyau peut continuer à produire, et le processus sur le côté droit du tuyau démarrera immédiatement après le démarrage du processus sur le côté gauche du tuyau. Démarré, mais il a été dans un état d'attente, attendant de recevoir les données transmises par le tuyau. .
En d’autres termes, les processus sur les côtés gauche et droit du pipeline se déroulent presque dans le désordre.
Alors, comment ps aux | grep "ssh" empêche-t-il le propre processus de grep d'apparaître dans les résultats ? Il existe deux méthodes :
Méthode 1 : ps aux | grep "ssh" | grep -v "grep"
Méthode 2 : ps aux grep "ss[ h ]"
[root@xuexi ~]# ps aux | grep ss[h] root 1211 0.0 0.1 82544 3600 ? Ss Jul26 0:00 /usr/sbin/sshd -D root 25236 0.0 0.2 145552 5524 ? Ss 05:28 0:00 sshd: root@pts/0 root 25720 0.0 0.2 145416 5524 ? Ss 06:15 0:00 sshd: root@pts/1
La première méthode consiste à appliquer la fonctionnalité "-v" de grep, et la deuxième méthode consiste à appliquer la fonctionnalité des expressions régulières.
En utilisant des tubes anonymes, vous avez peut-être découvert que les processus des deux côtés du tube appartiennent au même groupe de processus, ce qui signifie que les données du côté gauche du tube peuvent être transmis uniquement au processus situé sur le côté droit du canal. Aucun processus ne peut lire ces données. Mais en plus des canaux anonymes, il existe également des canaux nommés. Un canal nommé stocke les données d'un processus dans un fichier canal (fifo). D'autres processus peuvent lire le fichier canal pour lire les données qu'il contient, ce qui signifie que les données sont. n'est plus restreint. Concernant les canaux nommés, veuillez vous référer au noyau du système d'exploitation Linux/unix ou aux livres de programmation, qui fourniront généralement des introductions détaillées.
1.8.2 Redirection
1.8.2.1 Bases de la redirection
Le plus courant Le fichier les descripteurs de l'entrée standard (stdin), de la sortie standard (stdout) et de la sortie d'erreur standard (stderr) sont respectivement 0, 1 et 2, où 0, 1 et 2 peuvent également être considérés comme leurs codes numériques. Les informations de sortie peuvent être considérées comme les informations imprimées à l'écran, et celle qui ne donne pas d'erreur est la sortie standard, et celle qui donne une invite d'erreur est la sortie d'erreur standard. Bien entendu, cette explication est biaisée. , mais c'est facile à comprendre. Vous pouvez également personnaliser vos propres descripteurs pour implémenter une redirection avancée. Leur utilisation pourra être présentée dans de prochains articles.
Entrée standard = /dev/stdin = code 0 = 5244ce0f219d400200727d01369fff50 ou >>
Erreur standard = /dev/stderr = code 2 = utilisez la notation 2> ou 2>>
95ec6993dc754240360e28e0de8de30a, 2> implémente la fonction d'écrasement, >>, 2>> implémente la fonction d'ajout, mais de79f8e1c8217b5a1daba58b63a3720e&1 et &> sont courants dans les scripts. Ils indiquent tous deux que stdout et stderr sont redirigés vers le même endroit, c'est-à-dire. , redirigé Diriger tout le contenu de sortie. Tel que le "&> /dev/null" le plus courant.
Lancer stdout ou stderr vers /dev/null signifie supprimer les informations de sortie. À l'inverse, rediriger /dev/null vers un fichier signifie effacer le fichier.
[root@xuexi ~]# cat /dev/null > ab.sh
De plus, il existe plusieurs façons d'effacer rapidement les fichiers
[root@xuexi ~]# > ab.sh [root@xuexi ~]# : > ab.sh # 或"true >ab.sh",其实它们都等价于">ab.sh" [root@xuexi ~]# echo '' > ab.sh [root@xuexi ~]# truncate -s 0 ab.sh # truncate命令用于收缩和扩展文件大小 [root@xuexi ~]# dd if=/dev/null of=ab.sh
最后最重要的一点:在有重定向符号的语句中,命令执行之前已经将文件截断了。所以如果正在编辑一个文件并将编辑的结果重定向回这个文件将出现异常,因为截断后就没有合适的内容用于编辑。一个简单的示例如下:
[root@xuexi ~]# head a.log > a.log
有些时候直接使用">"覆盖输出是比较危险的。可以使用set -C来设置如果输出重定向文件已经存在则不覆盖。使用set +C来取消set -C的效果。如果在设置了set -C时仍然想强制覆盖,可以使用“>|”代替“>”来重定向输出。同理错误输出也有此特性。
[root@xuexi tmp]# set -C [root@xuexi tmp]# cat flip >ttt.txt -bash: ttt.txt: cannot overwrite existing file [root@xuexi tmp]# cat flip >| ttt.txt [root@xuexi tmp]# set +C
1.8.2.2 cat和重定向配合
配合cat使用可以分行输入内容到文件中。
[root@xuexi tmp]# cat <<eof>log.txt # 覆盖的方式输入到log.txt > this is stdin character > eof
也可以使用下面的方法。
[root@xuexi tmp]# cat >log1.txt <<eof > this is stdin character first! > eof
一方面,eof部分都必须使用"88a41d6e50d3a6dd535eaf0181fbf000log1.txt表示将document的内容覆盖到log1.txt文件中,如果是要追加,则使用>>log1.txt。所以,追加的方式如下:
[root@xuexi tmp]# cat >>log1.txt <<eof > this is stdin character first! > eof
或
[root@xuexi tmp]# cat <<eof>>log1.txt > this is stdin character first! > eof
1.8.2.3 tee双重定向
可以使用tee双重定向。一般情况下,重定向要么将信息输入到文件中,要么输出到屏幕上,但是既想输出到屏幕又想输出到文件就比较麻烦。使用tee的双重定向功能可以实现该想法。如图。
tee [-a] file
选项说明:
-a:默认是将输出覆盖到文件中,使用该选项将变为追加行为。
file:除了输出到标准输出中,还将输出到file中。如果file为"-",则表示再输入一次到标准输出中。
例如下面的代码,将a开头的文件内容全部保存到b.log,同时把副本交给后面的的cat,使用这个cat又将内容保存到了x.log。其中"-"代表前面的stdin。
[root@xuexi tmp]# cat a* | tee b.log | cat - >x.log
还可以直接输出到屏幕:
[root@xuexi tmp]# cat a* | tee b.log | cat
tee默认会使用覆盖的方式保存到文件,可以使用-a选项来追加到文件。如:
[root@xuexi tmp]# cat a* | tee -a b.log | cat
现在就可以在使用cat和重定向创建文件或写入内容到文件的同时又可以在屏幕上显示一份。
[root@xuexi tmp]# cat <<eof | tee ttt.txt > x y > z 1 > eof x y z 1
1.8.2.4 <<和<<<
在bash中,<<和<<<是特殊重定向符号。<<表示的是here document,<<<表示的是here string。
here document在上文已经解释过了,对于here string,表示将<<<后的字符串作为输入数据。
例如:
passwd --stdin user <<< password_value
等价于:
echo password_value | passwd --stdin user
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!