<![CDATA[Forum Ubuntu-fr.org / [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?id=355509 Sun, 15 Nov 2009 15:09:54 +0000 FluxBB <![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3070204#p3070204 Totor a écrit :

Bonjour,

FRUiT a écrit :

Un très très très grand mega merci à toi Totor ! d'avoir pris du temps pour étudier cette question, pour avoir trouvé une solution, et pour tout le reste smile

You're wellcome !


Ta méthode est astucieuse. Je crains toutefois que tu aies quelques propblèmes de lenteur. Surtout si la commande source de l'erreur est issue d'un traitement très long (ex. traitement video wink)

En réfléchissant très dur au problème je pense que dans l'ensemble mis à part une ou 2 commandes vraiment spécifiques ça devrait fonctionner pas mal. L'exemple que tu proposes est d'ailleurs excellent.
Il faut clairement distinguer le type d'erreur à laquelle on a à faire.
1) Erreur de syntaxe, de formulation, de paramètres, fichier absent etc.
Dans ce cas la commande s'exécute mais s'arrète aussitôt, pour délivrer le message d'erreur, et le processus (exemple traitement video) ne démarre pas ! exécuter une 2ème fois la commande ne retarde que de très peu l'apparition du prompt suivant.

2) La commande est bonne et le processus démarre
Dans ton exemple de traitement video, si le processus est engagé, c'est que la commande a réussi. Et donc les erreurs qui pourraient éventuellement être générées pendant ce processus sont généralement gérées pendant et par celui ci. Dans un tel cas la commande ne s'exécutera donc pas 2 fois.

Globalement je n'ai pas encore trouvé de commande générant une erreur qui soit longue au point que ma méthode serait inacceptable. Ceci dit tu as raison et c'est ce à quoi je faisais allusion par "ce n'est pas très propre comme méthode". c'est la raison pour laquelle je disais dans mon précédent message que je dois encore aprofondir et tester de plus belle.

Totor a écrit :

Sans compter sur la manipulation de l'historique à chaque instruction (minime je pense selon la taille autorisée, mais tout de même) !

Ca je l'avais déjà bien avant de commencer mes redirections de stderr. J'ai mis 20000 entrées comme option dans mon bashrc pour l'historique (mais je pense que c'est bien au delà du max j'ai pas vérifié) et ce petit processus de log est instantané et invisible, même sur un eeepc 901 pas vraiment super véloce.

Totor a écrit :

Par ailleurs, il se peut que ce ne soit pas fiable : supposons qu'une erreur ait pour origine une mauvaise valeur d'une variable d'environnement. Or, puisque tu lances bash en mode non intéractif, le bashrc ne sera pas chargé. les variables d'environnement ne sont donc pas chargées. De toute façon, puisque tu lances une instance de bash, le contexte reste totalement différent, il se peut donc que tu n'obtiennes pas le même résultat.

Ca c'est tout à fait exact et bien que j'ai pas non plus rencontré d'exemples jusque là non plus, je m'y attends. Je posterai des retours plus tard quand j'aurai testé un mois ou deux.

Totor a écrit :

A noter qu'en te relisant, j'ai trouvé une erreur dans mon script :
remplacer trap 'exec 2>&4 DEBUG' par trap 'exec 2>&4' DEBUG

J'ai corrigé également dans mon post, histoire de ne pas prèter à confusion pour d'éventuels lecteurs.

Totor a écrit :
FRUiT a écrit :

- Le résultat est un flux sous forme de "lignes" et non sous forme de "messages d'erreur"

En utilisant le principe que tu utilises de gestion de l'historique, on doit pouvoir remédier à cela (sauf pour "les command hint").

Je n'ai pas testé vraiment à fond mais j'ai eu des difficultés à rassembler ces 'lignes' dans un seul message global. Le problème étant à mon avis que ta fonction lit un 'flux' (venant du fifo) et non le résultat précis d'une commande en particulier.

Totor a écrit :
FRUiT a écrit :

- Le formattage (espaces tabulations) des messages d'erreur est parfois perdu (exemple commande 'sed' sans argument)

étonnant ?
as-tu déterminer à quel moment le formatage est perdu ?
as-tu essayé un echo -e ?

J'ai essayé 'echo -e' effectivement, d'ailleurs ne serait-ce que pour colorer en rouge c'est un peu obligatoire.
Sur la commande 'sed' sans argument les tabulations pour distinguer les options de leur description sont perdues je ne sais pas vraiment pourquoi. La même commande avec ma méthode (qui envoie pourtant le texte dans un autre script, qui se termine bien sur également par un 'echo -e') et là, les tabulations sont respectées...
Pourtant, ta méthode respecte le formatage sur d'autres commandes... Peut-être est-ce simplement une histoire de guillemets je tenterai également d'approfondir.

Totor a écrit :
FRUiT a écrit :

- L'ordre des flux stderr et stdout n'est pas respecté MAIS les flux ne sont pas mélangés

peux-tu préciser car je ne vois pas où tu gères la sortie standard et l'intérêt ?

Alors je me suis mal exprimé encore une fois big_smile
Certains programmes envoient une partie de l'erreur sur stderr, et affichent directement eux même une autre partie. Exemple : la commande 'sudo aptitude giant-upgrade' provoque une erreur. Admettons que nous colorons en rouge stderr. Une partie du message sera affichée de la couleur par défaut, et une petite partie seulement (une ligne en fait : 'Commande inconnue « giant-upgrade » ') transitera dans sdterr et sera affichée en rouge.

Avec ta méthode, cette partie rouge peut se retrouver aléatoirement au début, au milieu, ou à la fin du message dans sa globalité. La commande exemple n'a qu'une ligne rouge parmi un texte de la couleur par défaut, ce n'est pas grave. Si c'étaient 10 lignes rouges et dix lignes normales, ce serait déjà plus ennuyeux bien que le cas est surement rare.

Avec ma méthode, ces deux 'parties' du message, sont affichées l'une apres l'autre, et toujours le rouge en 2eme. (puisqu'une partie provient de la commande exécutée en premier, et l'autre de la commande exécutée une seconde fois dans PROMPT_COMMAND).

En fait je ne 'gère' pas la sortie standard dans ma fonction 'PROMPT_COMMAND', elle s'affiche d'elle même une fois la commande lancée.

Et les flux ne sont pas respectés non plus par ma méthode car stderr s'affichera toujours et obligatoirement en 2eme (cet aspect m'arrange aussi fortement). Dans la commande exemple ('sudo aptitude giant-upgrade'), en temps normal (sans redirections) le message d'erreur s'affiche en premier ('Commande inconnue « upgrrrrrade » '), puis le reste du texte alors qu'avec ma méthode cet ordre n'est plus respecté. Cela doit dépendre des commandes.

J'espère avoir été clair hmm


En fait pour le moment je vais passer un certain temps avec ma méthode, observer et noter ce qui se passe au fil des mes utilisations, je ferai ensuite de même avec ta méthode. Dans tout les cas je note précieusement ce petit code magique que tu m'as grâcieusement offert !! smile smile smile

Encore marci smile

]]>
Sun, 15 Nov 2009 15:09:54 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3070204#p3070204
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3066657#p3066657 Bonjour,

FRUiT a écrit :

Un très très très grand mega merci à toi Totor ! d'avoir pris du temps pour étudier cette question, pour avoir trouvé une solution, et pour tout le reste smile

You're wellcome !


Ta méthode est astucieuse. Je crains toutefois que tu aies quelques propblèmes de lenteur. Surtout si la commande source de l'erreur est issue d'un traitement très long (ex. traitement video wink) Sans compter sur la manipulation de l'historique à chaque instruction (minime je pense selon la taille autorisée, mais tout de même) !
Par ailleurs, il se peut que ce ne soit pas fiable : supposons qu'une erreur ait pour origine une mauvaise valeur d'une variable d'environnement. Or, puisque tu lances bash en mode non intéractif, le bashrc ne sera pas chargé. les variables d'environnement ne sont donc pas chargées. De toute façon, puisque tu lances une instance de bash, le contexte reste totalement différent, il se peut donc que tu n'obtiennes pas le même résultat.


A noter qu'en te relisant, j'ai trouvé une erreur dans mon script :
remplacer trap 'exec 2>&4 DEBUG' par trap 'exec 2>&4' DEBUG

FRUiT a écrit :

- Le résultat est un flux sous forme de "lignes" et non sous forme de "messages d'erreur"

En utilisant le principe que tu utilises de gestion de l'historique, on doit pouvoir remédier à cela (sauf pour "les command hint").

FRUiT a écrit :

- Le formattage (espaces tabulations) des messages d'erreur est parfois perdu (exemple commande 'sed' sans argument)

étonnant ?
as-tu déterminer à quel moment le formatage est perdu ?
as-tu essayé un echo -e ?

FRUiT a écrit :

- L'ordre des flux stderr et stdout n'est pas respecté MAIS les flux ne sont pas mélangés

peux-tu préciser car je ne vois pas où tu gères la sortie standard et l'intérêt ?

]]>
Sat, 14 Nov 2009 08:50:14 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3066657#p3066657
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3066249#p3066249 Bonjour Totor smile

Pardonne moi d'avoir mis du temps à te répondre, il a fallu que j'étudie de très près ta solution. De mon coté j'ai bien étudié également et suis arrivé à un résultat plutôt satisfaisant. Chacune des 2 méthodes présente un certain nombre d'avantages et d'inconvénients que je vais tenter d'expliquer au mieux.

La méthode Totor

 
 
function traceErreurs()
{
  logFile="$1"
  while read -u 4 LIGNE
  do
   [ "${LIGNE}" = "END" ] && break;
   [ Traitement spécifique de ton erreur ]
  done
}

mkfifo /tmp/$$.pipe
exec 4<>/tmp/$$.pipe
traceErreurs ~/$$.log &

exec 3>&2
PROMPT_COMMAND='exec 2>&3'
trap 'exec 2>&4' DEBUG


et dans le fichier ~/.bash_logout, rajoute ceci :


echo "END" >&4
rm -f /tmp/$$.pipe

Les plus
- Solution "propre" (en tout cas comparé à la mienne)
- Exécute une seule fois toute commande
- Permet de loguer dans un fichier, eventuellement formatté sous forme de sessions
- Donne tout le contenu de stderr (notemment les "command hints")

Les moins
- Utilse 2 fd supplémentaires (fd3 et fd4) ainsi que mkfifo et au moins un fichier sur le disque
- Le résultat est un flux sous forme de "lignes" et non sous forme de "messages d'erreur"
- Le formattage (espaces tabulations) des messages d'erreur est parfois perdu (exemple commande 'sed' sans argument)
- L'ordre des flux stderr et stdout n'est plus respecté (mélange entre les 2)

La méthode FRUiT

 
 
# Enable DEBUG trap
set -o functrace
shopt -s extdebug

PROMPT_COMMAND='
  ENUM=$?
  LCMD="$(history 1 | sed -e "s/^[ ]*[0-9]*[ ]*//g")"
  history -a; history -r
  if [ $ENUM -ne 0 ]; then
    EMSG=$( bash -c "${LCMD} 2>&1 >/dev/null" )
    # Code à compléter exemple : envoyer la variable dans un script :
    # msgd -m fail "\033[31m$EMSG\033[0m" "\033[31m"
    # msgd -e "Error $ENUM"
  else
    # Commande réussie
    echo "${LCMD}" >> /home/fruit/misc/knowledge/global_history
  fi
  # La DERNIERE ! instruction de la variable PROMPT_COMMAND
  exec 2>&4
'

# Les deux DERNIERES ! lignes de bashrc
exec 4>&2
trap 'exec 2>/dev/null' DEBUG

Les plus
- N'utilise qu'un seul fd supplémentaire
- N'utilise pas mkfifo et donc pas de nouveau fichier utilisant le disque
- N'utilise pas '~/.bash_logout' ou son équivalent
- Le résultat est une variable en mémoire contenant le message d'erreur entier
- Le formattage des messages d'erreurs est conservé, mếme en envoyant dans un script annexe
- L'ordre des flux stderr et stdout n'est pas respecté MAIS les flux ne sont pas mélangés

Les moins
- Exécute une 2eme fois toute commande ayant provoqué une erreur (possibilités de ralentissement sur de grosses commandes)
- Lance un sous-shell pour chaque erreur
- N'affiche pas les "command hints"


Notes
Dans  ce cas précis je préfère travailler avec des variables (plus maléables et "expansables") qu'avec des fichiers.

En fait le traitement 'par lignes' est idéal dès lors qu'il s'agit simplement de colorer les messages d'erreurs. Lorsque les manipulations sont plus complexes cela se gâte un peu, car il devient compliqué de récupérer le message d'erreur entier. Exemple je veux envoyer le résultat à un script de traitement, il devient plus commode (même obligatoire) d'envoyer l'erreur entièrement et non envoyer chaque ligne au script.

En fait de ces deux pistes, la mienne 'semble' me convenir mieux (je reposterai mes impressions après avoir longuement testé chaque méthode) bien que la piste de Totor me semble d'emblée beaucoup plus propre. Il n'en reste pas moins que les deux pistes fonctionnent parfaitement. Pour tout dire je pensais courrir après une chimère, mais finalement ça se met en oeuvre assez facilement.

Un très très très grand mega merci à toi Totor ! d'avoir pris du temps pour étudier cette question, pour avoir trouvé une solution, et pour tout le reste smile

]]>
Fri, 13 Nov 2009 23:13:02 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3066249#p3066249
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3057147#p3057147 n3o51 a écrit :

Bonsoir est ce que cela va permettre de rediriger tous les messages erreurs et autres dans un fichiers ?

Oui, remplace [ Traitement spécifique de ton erreur ] par tout ce que tu veux (donc potentielement rediriger vers un fichier)

D'ailleurs, dans mes tests, c'était ce que je faisais. La variable logFile dans la méthode traceErreurs est faite pour cela.

]]>
Tue, 10 Nov 2009 19:57:36 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3057147#p3057147
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3056597#p3056597 Bonsoir est ce que cela va permettre de rediriger tous les messages erreurs et autres dans un fichiers ?

Car moi j'ai un soucis sous wmii tous au terminal d'ailleurs j'utilise pratiquement que des programmes en terminal est je voudrais que quand je lance firefox trés rarement d'ailleurs j'ai tente par exemple firefox &
ou encore d'autres choses comme renvoyer les erreurs dans /dev/null mais rien de pratique

]]>
Tue, 10 Nov 2009 17:04:53 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3056597#p3056597
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3056391#p3056391 FRUiT a écrit :

(A noter également que pour tester j'ai temporairement désactivé le sourçage de .bash_completion)

C'est ce que je voulais tester ainsi que le mode non interactif.

FRUiT a écrit :

Sinon pour traiter les erreurs et les parser je stocke l'erreur de la commande dans une variable. Ca marche mais c'est vraiment pas propre sad Là, mon eeepc901 de test à plus de batteries je collerai un exemple ce soir.

De mon côté, je pensais à un système de pipe avec un process qui le lit.

EDIT :
Voilà une solution (dans le bashrc) :

function traceErreurs()
{
  logFile="$1"
  while read -u 4 LIGNE
  do
   [ "${LIGNE}" = "END" ] && break;
   [ Traitement spécifique de ton erreur ]
  done
}

mkfifo /tmp/$$.pipe
exec 4<>/tmp/$$.pipe
traceErreurs ~/$$.log &

exec 3>&2
PROMPT_COMMAND='exec 2>&3'
trap 'exec 2>&4 DEBUG'

et dans le fichier ~/.bash_logout, rajoute ceci :

echo "END" >&4
rm -f /tmp/$$.pipe
]]>
Tue, 10 Nov 2009 15:39:59 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3056391#p3056391
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3056303#p3056303 Totor a écrit :

Sinon, je rectifie un point :
le exec 2>/dev/null directement dans le fichier ne freeze pas le terminal.
La saisie est toujours possible mais puisque l'entrée standard est redirigée vers la sortie d'erreur alors ce qui est saisie au clavier ne s'affiche pas. Elle est tout de même interprétée une fois que l'on valide la saisie.

C'est exactement ce que je voulais dire par "taper à l'aveuglette", tout marche, mais sans rien voir. Pour un ls ou un cd ça va encore, mais pour les commandes compliquées c'est plutôt dur dur big_smile Et donc comme je disais, tout le prompt ainsi que la saisie au clavier sont dirigés sur stderr donc dans le fichier ou process ou null, ce qu'à ce jour je ne m'explique toutjours pas ^^ (pk pas sur stdout ? ...)

Bizarre pour cette différence entre chez toi et le travail... Peut-être la version de bash ?
(A noter également que pour tester j'ai temporairement désactivé le sourçage de .bash_completion)

Sinon pour traiter les erreurs et les parser je stocke l'erreur de la commande dans une variable. Ca marche mais c'est vraiment pas propre sad Là, mon eeepc901 de test à plus de batteries je collerai un exemple ce soir.

]]>
Tue, 10 Nov 2009 14:55:43 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3056303#p3056303
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3055441#p3055441 Totor a écrit :

[...]cela devient plus difficile car la méthode 2> >(process) renvoi la sortie d'erreur ET la sortie standard vers le process

Huum, étrange : chez moi la sortie stantard est redirigée vers le fichier alors qu'au TAF elle ne l'est pas ...
bon, 'faudra que je comprenne pourquoi...

Sinon, je rectifie un point :
le exec 2>/dev/null directement dans le fichier ne freeze pas le terminal.
La saisie est toujours possible mais puisque l'entrée standard est redirigée vers la sortie d'erreur alors ce qui est saisie au clavier ne s'affiche pas. Elle est tout de même interprétée une fois que l'on valide la saisie.

]]>
Tue, 10 Nov 2009 09:11:58 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3055441#p3055441
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3055101#p3055101 Oui j'ai pas encore testé mais je pense qu'il vaut mieux diriger dans un fichier et le traiter, je dois encore faire des tests.

Pour le fd4 j'avoue avoir choisi totalement au hasard. J'ai lu qu'il vallait mieux évider le fd3 qui apparemment sert souvent. J'ai rien lu de spé à propos du 4 qui est souvent choisi en exemple de duplication de fd2.

]]>
Tue, 10 Nov 2009 00:28:28 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3055101#p3055101
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3053976#p3053976 Bonsoir,
c'est ce que j'allais te proposer (en toute sincèrité) mais avant, je devais regarder pour choisir un fd aléatoire car il se peut que le 4 soit déjà choisi.
et puis, j'ai besoin de vérifier certaines choses...

EDIT :
Il semble que cela ne suffise pas. En effet, mettre tous les messages d'erreurs dans /dev/null fonctionne très bien mais si tu souhaites traiter ces messages, cela devient plus difficile car la méthode 2> >(process) renvoi la sortie d'erreur ET la sortie standard vers le process.

]]>
Mon, 09 Nov 2009 18:16:57 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3053976#p3053976
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3053462#p3053462 Bon j'ai trouvé

Tout à la fin de /etc/bash.bashrc

 
 
exec 4>&2
trap 'exec 2>/dev/null' DEBUG

Les options qui vont bien (toujours dans bashrc)

 
 
set -o functrace >/dev/null 2>&1
shopt -s extdebug >/dev/null 2>&1

Et la variable PROMPT_COMMAND (toujours dans bashrc)

 
 
PROMPT_COMMAND='
  # Commandes géantes
  exec 2>&4
'

Explication :

- trap exécute une commande AVANT celle entrée sur la ligne de comande, on redirige les erreurs dans /dev/null à ce moment ci.

- La commande s'exécute sans retour d'erreur.

- Juste après l'exécution de la commande s'exécute la variable 'PROMPT_COMMAND', qui contient la restauration de la sortie d'erreur (exec 2>&4) afin que le prompt puisse s'afficher correctement, ainsi que la frappe suivante au clavier. Le contenu de la variable s'exécute à la fin d'une commande juste avant l'affichage du prompt suivant.

- La boucle est bouclée.

Ca fait quand même énormément de manipulations pour pas grand chose... Une simple redirection permanente... Reste la question, mais pourquoi le prompt et la frappe au clavier sont ils dirigés sur stderr ??? Ce serait tellement simple sur stdout... Enfin bon ça marche tout de même mais j'aimerais connaitre l'explication de ce choix de bash qui semble absurde...

]]>
Mon, 09 Nov 2009 15:32:29 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3053462#p3053462
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3053228#p3053228 Désolé si je manque de clarté sad j'essaye d'expliquer le plus courtement pour ne pas embrouiller. Si besoin est je peux évidemment fournir toute information utile. Sinon ce n'est pas du tout pressé y'a pas de problèmes ^^

Grand merci à toi Totor smile

]]>
Mon, 09 Nov 2009 13:59:48 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3053228#p3053228
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3053046#p3053046 je vais essayer de prendre du temps pour regarde ce soir, mais je ne te garanti rien...
il faut que je vois exactement le comportement et que je le comprenne

]]>
Mon, 09 Nov 2009 12:51:51 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3053046#p3053046
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3051883#p3051883 Totor a écrit :
FRUiT a écrit :

[...] et là tout ce que j'ai pu tenter (un sacré paquet de commandes lol) ne marche pas. [...]

as-tu essayé ceci ?

exec 2 > >(tee -a fichier.log >/dev/null)

Hé non lol, et bonne idée smile hélas ça revient au même que :
exec 2>/dev/null
à ceci près que le fichier log contient bien les erreurs, mais du coté de la console, le prompt ne s'affiche pas (ou plutôt il s'affiche dans le fichier)

Totor a écrit :
FRUiT a écrit :

Ou si vous savez comment afficher le prompt et / ou sur stdout ? big_smile

Voici ce qui pourrait être une astuce :
Dans ton fichier ~/.bashrc (ou ~/.bash_profile), tu te crées une fonction qui affiche le prompt que tu souhaites (via printf ou echo) et qui valorise PS1 à vide. (Attention à bien faire un echo -en "<PROMPT SOUHAITE>" afin qu'il n'y ai pas de retour à la ligne. Par ailleurs, les caractères d'échapements bash pour afficher le prompt ne seront pas utilisables ! (c.a.d ceux décrits dans la section INVITES du manuel bash)

Toujours dans le fichier d'initialisation, tu ajoutes la ligne PROMPT_COMMAND=nomDeTaFonction (après la déclaration de ta fonction)

Ca j'ai tenté.
Le problème c'est que, certes, le prompt s'affiche, et le curseur également, mais je ne vois pas les commandes tapées avant d'avoir appuyé sur entrée ce qui est quelque peu fâcheux... Donc le problème reste entier.

Totor a écrit :

Note : je n'ai testé aucune des 2 propositions mais c'est ce que je tenterai dans un premier temps

Merci Totor pour ces précieux conseils. J'ai également cherché un peu du coté de la fonction trap qui exécute une commande avant celle entrée (trouvé dans le script ci dessous), en l'utilisant sous cette forme :

 
 
trap '#commande géante' DEBUG

avec comme options :

set -o functrace > /dev/null 2>&1
shopt -s extdebug > /dev/null 2>&1

Je dois approfondir mais rien de bien tangible jusque là non plus.

J'ai aussi récupéré un script 'preexec' que je n'ai pas encore testé, peut-être y a-t-il des possibilités de ce coté...

prexec

 
 
#!/bin/bash

# preexec.bash -- Bash support for ZSH-like 'preexec' and 'precmd' functions.

# The 'preexec' function is executed before each interactive command is
# executed, with the interactive command as its argument.  The 'precmd'
# function is executed before each prompt is displayed.

# To use, in order:

#  1. source this file
#  2. define 'preexec' and/or 'precmd' functions (AFTER sourcing this file),
#  3. as near as possible to the end of your shell setup, run 'preexec_install'
#     to kick everything off.

# Note: this module requires 2 bash features which you must not otherwise be
# using: the "DEBUG" trap, and the "PROMPT_COMMAND" variable.  preexec_install
# will override these and if you override one or the other this _will_ break.

# This is known to support bash3, as well as *mostly* support bash2.05b.  It
# has been tested with the default shells on MacOS X 10.4 "Tiger", Ubuntu 5.10
# "Breezy Badger", Ubuntu 6.06 "Dapper Drake", and Ubuntu 6.10 "Edgy Eft".


# Copy screen-run variables from the remote host, if they're available.

if [[ "$SCREEN_RUN_HOST" == "" ]]
then
    SCREEN_RUN_HOST="$LC_SCREEN_RUN_HOST"
    SCREEN_RUN_USER="$LC_SCREEN_RUN_USER"
fi

# This variable describes whether we are currently in "interactive mode";
# i.e. whether this shell has just executed a prompt and is waiting for user
# input.  It documents whether the current command invoked by the trace hook is
# run interactively by the user; it's set immediately after the prompt hook,
# and unset as soon as the trace hook is run.
preexec_interactive_mode=""

# Default do-nothing implementation of preexec.
function preexec () {
    true
}

# Default do-nothing implementation of precmd.
function precmd () {
    true
}

# This function is installed as the PROMPT_COMMAND; it is invoked before each
# interactive prompt display.  It sets a variable to indicate that the prompt
# was just displayed, to allow the DEBUG trap, below, to know that the next
# command is likely interactive.
function preexec_invoke_cmd () {
    precmd
    preexec_interactive_mode="yes"
}

# This function is installed as the DEBUG trap.  It is invoked before each
# interactive prompt display.  Its purpose is to inspect the current
# environment to attempt to detect if the current command is being invoked
# interactively, and invoke 'preexec' if so.
function preexec_invoke_exec () {
    if [[ -n "$COMP_LINE" ]]
    then
        # We're in the middle of a completer.  This obviously can't be
        # an interactively issued command.
        return
    fi
    if [[ -z "$preexec_interactive_mode" ]]
    then
        # We're doing something related to displaying the prompt.  Let the
        # prompt set the title instead of me.
        return
    else
        # If we're in a subshell, then the prompt won't be re-displayed to put
        # us back into interactive mode, so let's not set the variable back.
        # In other words, if you have a subshell like
        #   (sleep 1; sleep 2)
        # You want to see the 'sleep 2' as a set_command_title as well.
        if [[ 0 -eq "$BASH_SUBSHELL" ]]
        then
            preexec_interactive_mode=""
        fi
    fi
    if [[ "preexec_invoke_cmd" == "$BASH_COMMAND" ]]
    then
        # Sadly, there's no cleaner way to detect two prompts being displayed
        # one after another.  This makes it important that PROMPT_COMMAND
        # remain set _exactly_ as below in preexec_install.  Let's switch back
        # out of interactive mode and not trace any of the commands run in
        # precmd.

        # Given their buggy interaction between BASH_COMMAND and debug traps,
        # versions of bash prior to 3.1 can't detect this at all.
        preexec_interactive_mode=""
        return
    fi

    # In more recent versions of bash, this could be set via the "BASH_COMMAND"
    # variable, but using history here is better in some ways: for example, "ps
    # auxf | less" will show up with both sides of the pipe if we use history,
    # but only as "ps auxf" if not.
    local this_command=`history 1 | sed -e "s/^[ ]*[0-9]*[ ]*//g"`;

    # If none of the previous checks have earlied out of this function, then
    # the command is in fact interactive and we should invoke the user's
    # preexec hook with the running command as an argument.
    preexec "$this_command"
}

# Execute this to set up preexec and precmd execution.
function preexec_install () {

    # *BOTH* of these options need to be set for the DEBUG trap to be invoked
    # in ( ) subshells.  This smells like a bug in bash to me.  The null stderr
    # redirections are to quiet errors on bash2.05 (i.e. OSX's default shell)
    # where the options can't be set, and it's impossible to inherit the trap
    # into subshells.

    set -o functrace > /dev/null 2>&1
    shopt -s extdebug > /dev/null 2>&1

    # Finally, install the actual traps.
    PROMPT_COMMAND="${PROMPT_COMMAND};preexec_invoke_cmd"
    trap 'preexec_invoke_exec' DEBUG
}

# Since this is the reason that 99% of everybody is going to bother with a
# pre-exec hook anyway, we'll include it in this module.

# Change the title of the xterm.
function preexec_xterm_title () {
    local title="$1"
    echo -ne "\e]0;$title\007" > /dev/stderr
}

function preexec_screen_title () {
    local title="$1"
    echo -ne "\ek$1\e\\" > /dev/stderr
}

# Abbreviate the "user@host" string as much as possible to preserve space in
# screen titles.  Elide the host if the host is the same, elide the user if the
# user is the same.
function preexec_screen_user_at_host () {
    local RESULT=""
    if [[ "$SCREEN_RUN_HOST" == "$SCREEN_HOST" ]]
    then
        return
    else
        if [[ "$SCREEN_RUN_USER" == "$USER" ]]
        then
            echo -n "@${SCREEN_HOST}"
        else
            echo -n "${USER}@${SCREEN_HOST}"
        fi
    fi
}

function preexec_xterm_title_install () {
    # These functions are defined here because they only make sense with the
    # preexec_install below.
    function precmd () {
        preexec_xterm_title "${TERM} - ${USER}@${SCREEN_HOST} `dirs -0` $PROMPTCHAR"
        if [[ "$TERM" == screen ]]
        then
            preexec_screen_title "`preexec_screen_user_at_host`${PROMPTCHAR}"
        fi
    }

    function preexec () {
        preexec_xterm_title "${TERM} - $1 {`dirs -0`} (${USER}@${SCREEN_HOST})"
        if [[ $TERM == screen ]]
        then
            local cutit="$1"
            local cmdtitle=`echo "$cutit" | cut -d " " -f 1`
            if [[ "$cmdtitle" == "exec" ]]
            then
                local cmdtitle=`echo "$cutit" | cut -d " " -f 2`
            fi
            if [[ "$cmdtitle" == "screen" ]]
            then
                # Since stacked screens are quite common, it would be nice to
                # just display them as '$$'.
                local cmdtitle="${PROMPTCHAR}"
            else
                local cmdtitle=":$cmdtitle"
            fi
            preexec_screen_title "`preexec_screen_user_at_host`${PROMPTCHAR}$cmdtitle"
        fi
    }

    preexec_install
}
]]>
Sun, 08 Nov 2009 21:50:29 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3051883#p3051883
<![CDATA[Réponse à : [RESOLU] exec, bashrc, redirections permanentes]]> http://forum.ubuntu-fr.org/viewtopic.php?pid=3051641#p3051641 FRUiT a écrit :

[...] et là tout ce que j'ai pu tenter (un sacré paquet de commandes lol) ne marche pas. [...]

as-tu essayé ceci ?

exec 2 > >(tee -a fichier.log >/dev/null)
FRUiT a écrit :

Ou si vous savez comment afficher le prompt et / ou sur stdout ? big_smile

Voici ce qui pourrait être une astuce :
Dans ton fichier ~/.bashrc (ou ~/.bash_profile), tu te crées une fonction qui affiche le prompt que tu souhaites (via printf ou echo) et qui valorise PS1 à vide. (Attention à bien faire un echo -en "<PROMPT SOUHAITE>" afin qu'il n'y ai pas de retour à la ligne. Par ailleurs, les caractères d'échapements bash pour afficher le prompt ne seront pas utilisables ! (c.a.d ceux décrits dans la section INVITES du manuel bash)

Toujours dans le fichier d'initialisation, tu ajoutes la ligne PROMPT_COMMAND=nomDeTaFonction (après la déclaration de ta fonction)

Note : je n'ai testé aucune des 2 propositions mais c'est ce que je tenterai dans un premier temps

]]>
Sun, 08 Nov 2009 20:30:24 +0000 http://forum.ubuntu-fr.org/viewtopic.php?pid=3051641#p3051641