Connaissez-vous un moyen d'enregistrer automatiquement les commandes qui retournent avec succès ... afin de garder une trace de la façon dont vous avez réussi à configurer votre environnement pour compiler ce morceau de code obstiné ?
Vous devez d'abord répondre à la question suivante Qu'est-ce qui constitue une commande réussie ?
Vous pensez probablement "c'est facile ! Un qui fonctionne et qui sort avec un code 0 !" Pour y voir plus clair, vous devez définir ce qu'est un code 0. commande ratée est. La définition la plus large sera toute commande dont le code de sortie est différent de zéro . Cela signifie-t-il que la commande a échoué ?
Non. Ce n'est pas le cas. Les commandes échouent pour un certain nombre de raisons et cela ne signifie pas que ce que vous avez tapé était une erreur. Prenons un exemple très simple : ssh . Si vous vous connectez à un serveur distant et quittez proprement (tapez exit lorsque vous avez terminé), vous obtiendrez un statut de sortie de zéro (0). Cependant, si vous poweroff la machine, vous obtiendrez un statut de sortie de un (1) lorsque les connexions sont rompues.
Votre commande a échoué ?
Essayez-le. Connectez-vous via SSH à n'importe quel ordinateur distant. Sortez proprement puis lancez la commande echo $? . Refaites-le, puis publiez poweroff ou fermez votre session sur la télécommande et recommencez la commande echo.
J'utilise également Zsh et j'ai créé une invite personnalisée qui fait précéder mon invite d'une coche verte. ![green check]()
ou un "X rouge" ![red x]()
selon que la dernière commande a échoué ou non.
Voici un exemple avec l'exemple SSH utilisé ci-dessus.
![Green Check Prompt]()
![Red X Prompt]()
La commande a-t-elle vraiment échoué ? Non, elle n'a pas échoué mais le résultat a généré un code d'erreur parce que quelque chose dans le fichier processus échoué. Cela s'applique également aux commandes que vous utilisez pour compiler des logiciels. Votre commande peut être syntaxiquement parfaite, mais la compilation échouera quand même parce que vous avez une erreur dans votre code. Voulez-vous que cette commande soit ignorée ?
Variable d'environnement BASH_COMMAND
Par curiosité, j'ai fait des recherches à ce sujet et ce n'est pas une chose banale à faire. Vous ne pouvez pas utiliser history parce qu'il est conçu pour être interactive et non scénarisée.
En Bash, il existe une varialbe d'environnement appelée $BASH_COMMAND . C'est la commande qui est sur le point d'être ou qui est en train d'être exécutée, sauf si la commande a été appelée à partir d'une commande Piège alors c'est la commande qui s'exécute au moment du piège.
Pour en tirer parti, vous devez exécuter toutes vos commandes dans un piège DEBUG :
trap ‘prev_command=$thiscmd; thiscmd=$BASH_CMD’ DEBUG
mycommand
if $? -eq 0; echo $prev_command >> somefile.txt; else echo “Command failed”; fi
Ce serait la logique, mais dans la pratique, ça ne marche pas parce que vous devez exécuter votre commande dans un piège.
Je n'ai pas trouvé d'équivalent dans Zsh (encore... mais je doute de continuer mes recherches).
Addons Zsh
Je suis sur un MacBook Pro, MacOS Catalina, utilisant iTerm2 avec zsh et l'extension oh-my-zsh, ainsi que powerlevel10k.
Je ne suis pas un fan de ces choses surtout pour les utilisateurs novices . Vous apportez beaucoup de complexité supplémentaire et de compléments pour embellir votre invite de commande et votre environnement shell. J'encourage les gens à apprendre à faire cela manuellement afin de comprendre les fondements de votre système.
Le code de mon exemple ci-dessus est en fait très simple :
PROMPT="%(?.%F{green}.%F{red})%fallan@%m %F{blue}%1~ %f%# "
En fait, je crée une fonction simple (en ~/.zshrc ou `~/.bash_profile) pour les cas où je dois couper/coller la sortie du terminal sur des forums publics comme celui-ci :
# (Re)sets the prompt on the fly
setprompt() {
case "$1" in
se) # Obfuscates username to "allan" for StackExchange posts
PROMPT="%(?.%F{green}.%F{red})%fallan@%m %F{blue}%1~ %f%# "
;;
*) # Default is to set the prompt back to the original
PROMPT=' %(?.%F{green}.%F{red})%f%n@%m %F{blue}%1~ %f%# '
;;
esac
}
En fin de compte, ce n'est vraiment pas faisable.
Évitez tous ces ajouts. Ce n'est qu'un habillage. Apprenez d'abord à utiliser la coque de base, puis ajoutez des éléments au fur et à mesure. Cela vous aidera à apprendre réellement le système. Vous cherchez des raccourcis pour certaines choses et cela va en fait nuire à votre efficacité.
TL;DR
Ne faites pas ça. Une commande qui a échoué n'est pas nécessairement une mauvaise commande. Vous pouvez très facilement "ignorer" une commande parfaitement bonne parce qu'elle a échoué en raison d'un problème non lié à la commande elle-même.
En général, je me contente de copier/coller les actions réussies que je fais en ligne de commande dans un fichier texte. C'est un processus un peu lourd et sujet aux erreurs, et j'oublie parfois de le faire.
Si vous trouvez que le copier/coller est source d'erreurs, c'est que vous vous y prenez mal. Si c'est encombrant et que vous oubliez, repensez votre flux de travail. J'ai toujours OneNote ouvert sur mon deuxième écran pour pouvoir m'y référer et prendre des notes dès que j'en ai besoin. Trouvez un flux qui vous convient. L'historique intégré de la coquille ne remplace pas une bonne prise de notes.
Non seulement ce n'est pas une bonne pratique dans l'ensemble, mais ce n'est pas faisable en raison de la façon dont vous vous y prendriez pour capturer la dernière commande réussie.
ou un "X rouge" 
selon que la dernière commande a échoué ou non.
