Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

Attention, une faille de sécurité dans bash vient d'être divulguée, il est recommandé de mettre à jour son système (plus de détails)

*** 28 sept. nouvelle mise à jour (4.2-2ubuntu2.5 ou 4.3-7ubuntu1.4) *** pour mettre à jour, lancez dans un terminal :
sudo apt-get update ; sudo apt-get upgrade bash

#1 Le 05/11/2009, à 02:24

FRUiT

[RESOLU] exec, bashrc, redirections permanentes

Yop la foule cool

Je tente de rajouter

exec 2>/dev/null

dans mon fichier bashrc (/etc/bash.bashrc pour être précis, mais le résultat est le même dans ~/.bashrc) et là ma console freeze au démarrage et je le vois même plus mon prompt... Comment ça se fait ? Que faire ?

Dernière modification par FRUiT (Le 09/11/2009, à 17:39)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#2 Le 05/11/2009, à 02:32

mydjey

Re : [RESOLU] exec, bashrc, redirections permanentes

exec 2> /dev/null

Et comme ça ?


Mon site : http://mydjey.eu/

Hors ligne

#3 Le 05/11/2009, à 03:41

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

Pareil.

J'ai testé dans un bashrc tout vierge pour voir si une autre quelconque commande entrait en conflit avec exec mais le résultat est le même.

En fait le /dev/null c'est pour l'exemple, un fichier normal ça donne... pareil big_smile

Grâce à une fonction de mon PROMPT_COMMAND, je vois que pendant que ça freeze j'ai un code erreur 1...

Pourtant on peut lire dans 'help exec'

exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
    Replace the shell with the given command.

    Execute COMMAND, replacing this shell with the specified program.
    ARGUMENTS become the arguments to COMMAND.  If COMMAND is not specified,
    any redirections take effect in the current shell.

Dernière modification par FRUiT (Le 05/11/2009, à 12:39)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#4 Le 05/11/2009, à 03:47

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

 
 
exec 2> >(tee -a fichier.log)

http://forum.ubuntu-fr.org/viewtopic.php?pid=2730723#p2730723
Cette commande proposée par totor... fonctionne !
Malheureusement, elle en fait  trop lol

Totor à l'aiiiiiiiiide lol


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#5 Le 06/11/2009, à 07:31

n3o51

Re : [RESOLU] exec, bashrc, redirections permanentes

tu veut l'utiliser comment aprés la commande ?
Tu veut que pour chaque commande la redirection d'erreur soit effectué ?
Qu'est qu'y vas pas avec celle de totor ?  elle fait quoi de trop ?

J'ai un peut de mal a pigé !!!


Welcome to the real world
________________________________

Hors ligne

#6 Le 06/11/2009, à 11:32

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

Ben pour commencer j'aimerais par exemple masquer (donc rediriger) les erreurs de ma console (dans le but ultérieur de les traiter et les parser)

La commande de totor marche, sauf que avec, les erreurs sortent bien dans un fichier mais apparaissent QUAND MEME dans la console. En d'autres termes c'est une double redirection (avec tee).

Moi je voudrais la même chose mais sans voir mes erreurs dans la console. et là tout ce que j'ai pu tenter (un sacré paquet de commandes lol) ne marche pas. Soit ce n'est pas effectif, soit ça freeze ma console et je ne peut plus m'en servir jusqu'à ce que je retire la commande exec de bashrc.


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#7 Le 06/11/2009, à 16:01

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

En fait (pour reformuler) je voudrais juste rediriger les erreurs de ma console de manière permanente, et sans les y afficher.


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#8 Le 06/11/2009, à 17:50

n3o51

Re : [RESOLU] exec, bashrc, redirections permanentes

ok ben je crois que tu peut faire ça je vais essayer de retrouver mais je pense que tu dois meme pouvoir balancer les erreurs dans un tty de façon permanente.

Je vais aller au plus vite on va demander a totor smile

Dernière modification par n3o51 (Le 06/11/2009, à 17:56)


Welcome to the real world
________________________________

Hors ligne

#9 Le 06/11/2009, à 19:10

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

Depuis 48h maintenant je fouille google à la recherche de cette solution sans arriver à mettre le doigt dessus sad


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#10 Le 06/11/2009, à 23:47

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

En fait en retestant ça marche, je pensais que ma console freezait mais en réalité, c'est que mon prompt sort DANS MON FICHIER D'ERREUR ???

Donc à l'écran je ne vois ni prompt ni ce que je tape, en revanche ma console marche bien si je tape à l'aveugle pas de problème tout fonctionne.

Donc je reformule :

Comment faire en sorte que mon prompt sorte sur STDOUT au lieu de STDERR ??

Dernière modification par FRUiT (Le 07/11/2009, à 01:59)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#11 Le 07/11/2009, à 10:18

n3o51

Re : [RESOLU] exec, bashrc, redirections permanentes

Tu as trouvé comment faire smile ?

     Moi rien pour l'instant ...


Welcome to the real world
________________________________

Hors ligne

#12 Le 07/11/2009, à 11:33

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

Non mais je n'ai pu que tester sans recherches sur le net. Je continue... neutral

Merci pour ton aide au fait smile


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#13 Le 08/11/2009, à 22:07

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

Bon finalement ça marche super. exemple colorer en rouge stderr :

 
 
function errors ()
{
  while read LI; do echo -e "\033[1;36m$LI\033[0m"; done
  # Ou autre code à exécuter :)
}


exec 2> >(errors)

Helas et il semblerait que ce soit normal, le prompt est dirigé sur stderr dans bash mad donc je le vois en rouge lui aussi, et la commande que je tape (ou si je décide de masquer stderr, le prompt n'apparait carrément plus du tout. ça marche néanmoins en tapant les commandes à l'aveuglette...). Si quelqu'un pouvait expliquer pourquoi stderr et pas plutôt stdout ? J'ai pas trouvé d'explication ?

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

D'avance marci.

Dernière modification par FRUiT (Le 08/11/2009, à 22:09)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#14 Le 08/11/2009, à 22:30

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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

Dernière modification par Totor (Le 08/11/2009, à 22:30)


-- Lucid Lynx --

Hors ligne

#15 Le 08/11/2009, à 23:50

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

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
}

Dernière modification par FRUiT (Le 09/11/2009, à 00:33)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#16 Le 09/11/2009, à 14:51

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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


-- Lucid Lynx --

Hors ligne

#17 Le 09/11/2009, à 15:59

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

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


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#18 Le 09/11/2009, à 17:32

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

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...

Dernière modification par FRUiT (Le 09/11/2009, à 17:48)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#19 Le 09/11/2009, à 20:16

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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.

Dernière modification par Totor (Le 09/11/2009, à 22:04)


-- Lucid Lynx --

Hors ligne

#20 Le 10/11/2009, à 02:28

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

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.

Dernière modification par FRUiT (Le 10/11/2009, à 02:34)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#21 Le 10/11/2009, à 11:11

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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.


-- Lucid Lynx --

Hors ligne

#22 Le 10/11/2009, à 16:55

FRUiT

Re : [RESOLU] exec, bashrc, redirections permanentes

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.

Dernière modification par FRUiT (Le 10/11/2009, à 17:07)


Neon Suite by FRUiT (kde4.6) http://tinyurl.com/yzm7cee
"Pour la carotte, le lapin est la plus parfaite incarnation du mal" (R. Sheckley)
clean

Hors ligne

#23 Le 10/11/2009, à 17:39

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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

Dernière modification par Totor (Le 10/11/2009, à 21:29)


-- Lucid Lynx --

Hors ligne

#24 Le 10/11/2009, à 19:04

n3o51

Re : [RESOLU] exec, bashrc, redirections permanentes

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


Welcome to the real world
________________________________

Hors ligne

#25 Le 10/11/2009, à 21:57

Totor

Re : [RESOLU] exec, bashrc, redirections permanentes

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.

Dernière modification par Totor (Le 10/11/2009, à 21:58)


-- Lucid Lynx --

Hors ligne

Haut de page ↑