Exemples de liner complexe Linux Bash

Bash One-Liners peut réduire la charge de travail, automatiser quelque chose rapidement et mettre la puissance du contrôle ultime du système entre vos mains. Au fil du temps, vous apprendrez probablement à écrire des doublures plus complexes et certaines des choses que vous finirez par écrire en tant que professionnel chevronné seront presque entravées par un débutant. Cela dit, le langage de commande et de développement Bash est très structuré - et relativement facile à comprendre - une fois que vous connaissez les et des absents. C'est vraiment comme devenir compétent dans une langue étrangère.

Dans ce tutoriel, vous apprendrez:

• Comment écrire des commandes et scripts plus avancés
• Comprendre comment combiner diverses commandes dans des scripts en une seule ligne
• Comprendre comment les codes de sortie d'une commande peuvent affecter d'autres commandes lors de l'utilisation && et ||
• Comprendre comment la contribution d'une commande peut être modifiée, puis être utilisée par la commande suivante
• Utilisation et des exemples de la vie réelle de Bash One-Liners plus avancés

Exigences et conventions logicielles utilisées

Exemple 1: contrôle du processus

Commençons par un exemple de la façon de terminer certains processus de Bash de manière facile à suivre:

$ sleep 3600 & [1] 1792341 $ ps -ef | Grep 'Sleep' Roel 1792441 1701839 0 12:59 PTS / 13 00:00:00 Sleep 3600 Roel 1792452 1701839 0 12:59 PTS / 13 00:00:00 Grep - Color = Auto Sleep 

Nous avons d'abord configuré une commande de sommeil, pendant 3600 secondes (une heure), et nous trouvons par la suite ce processus dans la liste de processus. Super, mais nous avons le réel grep Commande en tant que ligne supplémentaire dans la sortie de la sortie de processus. Filtrons cela et extrons également l'ID de processus ensuite au lieu de la sortie complète des informations du processus:

$ ps -ef | grep «sommeil» | grep -v grep roel 1792441 1701839 0 12:59 pts / 13 00:00:00 Sleep 3600 $ ps -ef | grep «sommeil» | grep -v grep | awk 'print $ 2' 1792441 

Dans la première commande, nous avons filtré le grep actif. Dans la deuxième commande, nous avons fait un peu plus loin en imprimant la deuxième colonne 2 $ (à l'intérieur awk) en utilisant le awk commande. Nous pouvons maintenant utiliser aller plus loin et en fait tuer ce processus. Disons que nous faisons ça avec le signal 9 qui est très destructeur pour tout processus Linux (Sigkill):

$ ps -ef | grep «sommeil» | grep -v grep | awk 'print $ 2' | xargs tuer -9 [1] + Sleep 3600 tué 3600 

Et nous pouvons voir que notre processus a été tué correctement. Alors que c'était un exemple plus simple, il impliquait 6 commandes différentes: ps, grep, grep encore, awk, xargs et tuer. Vous pouvez voir comment Bash One-Liners peut rapidement renforcer la complexité de différentes manières et à de nombreux niveaux de complexité et de capacité de traitement des données.

Et, pour en savoir plus sur les xargs, veuillez consulter nos articles Xargs pour les débutants avec des exemples et des xargs multiples avec des exemples.

Exemple 2: Fun avec succès et échec!

$ echo '0'> a && echo '1'> b && echo '2'> c && ls DoESNOTEXist || ls a && ls b && ls c && ls d && ls e ls: ne peut pas accéder à «netNotexist»: aucun fichier ou répertoire de ce type a b c ls: ne peut accéder à «D»: aucun fichier ou répertoire de ce type 

Quelle ligne complexe! Pourtant, une fois que vous savez comment le lire, ou peut-être que vous le faites déjà, cela devient très facile à lire. Démontrez-vous que cette affirmation est valide en brisant la commande dans des morceaux plus petits de la taille d'une bouchée qui sont plus faciles à comprendre et à suivre:

$ echo '0'> a && echo '1'> b && echo '2'> c 

Tout cet ensemble de commandes est le même que le suivant avec une petite mise en garde:

$ echo '0'> a $ echo '1'> b $ echo '2'> c 

Alors quelle est la différence (et la petite mise en garde)?

Que dans cette dernière série de commandes, chaque commande sera exécutée, quel que soit le résultat de la commande précédente. La séquence précédente (en utilisant &&) ne fera que le second écho si Le résultat du premier commandement était 0 (je.e. Succès - Dans Bash, le succès dans une commande est indiqué par 0 et échec avec 1 ou plus comme un code de sortie).

Ainsi, la séquence de commande en utilisant && pourrait également être écrit comme suit;

$ echo '0'> a $ si [$ ? -eq 0]; puis écho '1'> b; fi $ si [$ ? -eq 0]; puis écho '2'> c; Fi 

Le $ ? (ou $? En syntaxe courte), la variable contient toujours le résultat de la dernière commande, je.e. le code de sortie (0, 1 ou plus) généré par la dernière commande.

Comme nous pouvons le voir, la création d'une ligne de echo '0'> a && echo '1'> b && echo '2'> c C'est sûrement plus facile dans les yeux et la compréhension maintenant, et cela réduit définitivement la complexité du code correspondant et correspondant affiché juste au-dessus.

Prenons ensuite une seule commande de plus:

$ echo '0'> a && echo '1'> b && echo '2'> c && ls ne dacksnotexist ls: ne peut pas accéder à 'DoSnotexist': pas de tel fichier ou répertoire de ce type 

Cela se lit maintenant beaucoup plus facile, juste?

Nous venons d'ajouter une autre commande à savoir LS ne fait pasxiste à condition que la commande avant lui (et dans ce cas toute la ligne entière comme toutes les commandes sont jointes par && Dans une configuration en forme de chaîne, où une commande défectueuse brisera la chaîne et arrête l'exécution de la chaîne en totalité) a réussi. Comme toutes les commandes réussissent, le LS est exécuté, et une erreur est produite à la suite de la même chose car le fichier, eh bien, n'existe vraiment pas 🙂

Alors que se passerait-il si nous rejoignions un autre && à la fin? La chaîne de commandes se terminerait-elle comme nous l'avons dit? Ajusterons un peu la commande:

$ echo '0'> a && echo '1'> b && echo '2'> c && ls nedNotexist && echo 'sûrement pas' ls: ne peut pas accéder 'netNotexist': aucun fichier ou répertoire de ce type 

Et, il n'a sûrement pas exécuté. Présentons ensuite notre prochaine commande dans notre chaîne à partir de l'exemple original:

$ echo '0'> a && echo '1'> b && echo '2'> c && ls DoESNOTEXist || ls a ls: ne peut pas accéder à «netNotexist»: aucun fichier ou répertoire de ce type A 

Pouvez-vous voir ce qui se passe? Ici, nous avons un nouveau symbole de syntaxe à savoir || qui est différent de && en ce qu'il s'exécute uniquement s'il y avait un résultat non nul dans la commande précédente. Notez que les deux || et && s'appliquer uniquement à la dernière commande, et non à la chaîne de commandes, même si l'on pouvait y penser comme une chaîne dans l'ensemble.

Vous pouvez donc penser à && Comme l'équivalent de la langue anglaise et et, dans une certaine mesure le commun et présent dans les langages de programmation, mais avec la torsion que nous vérifions ici une condition avant le && et exécuter ce qui est derrière à condition que la condition de sortie soit 0.

Une autre torsion est que la plupart des langages de programmation vérifieront véracité En tant que binaire 1 quand && La syntaxe est utilisée. Par exemple, considérez le code pseudo; Si test1_flag && test2_flag alors… qui évaluera généralement à vrai dans l'ensemble (et ainsi exécuter le alors commandes) Si les drapeaux binaires test1_flag et test2_flag sont 1 ou vrai, alors que dans le bash véracité est indiqué par un 0 (et pas 1) Sortez l'état de la dernière commande!

Vous pouvez penser à || Comme l'équivalent de la langue anglaise ou (ou un péché ou si cela échoue, faites-le… ). Dans cette situation, il existe un lien plus fort avec les langages de programmation communs: lorsqu'un langage de programme commun vérifie, par exemple Si test1_flag || test2_flag alors… , Puis un positif binaire test1_flag (je.e. valeur 1) ou test2_flag donnerait la condition globale pour être vraie (et donc le alors la clause serait exécutée). Nous voyons la même chose à Bash; Si le code de sortie de la commande est non nul (i.e. 1 ou une valeur plus élevée dans certains cas), puis la commande derrière le || La clause sera exécutée.

Revenons maintenant à la commande originale et analysez-la en entier:

$ echo '0'> a && echo '1'> b && echo '2'> c && ls DoESNOTEXist || ls a && ls b && ls c && ls d && ls e ls: ne peut pas accéder à «netNotexist»: aucun fichier ou répertoire de ce type a b c ls: ne peut accéder à «D»: aucun fichier ou répertoire de ce type 

Pouvez-vous voir ce qui se passe? Parce que le LS ne fait pasxiste La commande échoue en interne et donne une sortie non nulle (utiliser ls ne fait pasxiste; Echo $? en bash pour vérifier; La sortie est 2), le ou (||) La clause est déclenchée et ensuite nous exécutons LS. Imaginez-le comme une chaîne qui coule vers une direction différente, mais c'est toujours une chaîne.

Comme le ls a la commande réussit et est suivie par le et (&&) clause, la commande suivante est exécutée et ainsi de suite. Notez que l'exécution arrive à LS D, et la sortie pour le même (LS: Impossible d'accéder à «D»: aucun fichier ou répertoire de ce type) est montré, mais le ls e La commande n'est pas exécutée! Ceci est attendu, comme && a été utilisé et le LS D La commande a échoué. Ainsi, ls e n'est jamais exécuté.

Conclusion

Plus vous devenez compétent en écriture, plus vite, mieux, moins sujet aux erreurs et plus fluide, vos scripts en une lignée deviendront, et moins vous passerez de temps à les écrire. Les développeurs du langage bash ont mis tout le contrôle entre vos mains. Que ferez-vous avec ce contrôle aujourd'hui?

Laissez-nous un message ci-dessous avec vos créations en une seule-line les plus cool!

Tutoriels Linux connexes:

• Une introduction à l'automatisation Linux, des outils et des techniques
• Choses à installer sur Ubuntu 20.04
• Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
• Masterring Bash Script Loops
• Récupération des pages Web à l'aide de WGet, Curl et Lynx
• Mint 20: Mieux que Ubuntu et Microsoft Windows?
• Ubuntu 20.04 Guide
• Boucles imbriquées dans les scripts bash
• Manipulation de Big Data pour le plaisir et le profit Partie 1
• Choses à faire après l'installation d'Ubuntu 22.04 Jammy Jellyfish…