Forum Programmation.shell Ctrl+c ferme xterm

Posté par (page perso) . Licence CC by-sa
Tags :
1
13
jan.
2014

Bonjour,

Ma question est assez idiote, mais voilà mon problème.

J'ai une application C++/Qt qui génère un script (index.csh), et l'exécute, jusque là, pas de problème.

Au début du script généré, il y a la commande:

git init

Cette commande peut être trop longue quand il y a beaucoup de fichiers dans le dossier en question.
Les utilisateurs aimeraient avoir la possibilités de faire un ctrl+C pour couper le "git init" et passer à la suite du script.
Seul problème, Le ctrl+C tue l'instance de xterm et le script s'arrête.

J'ai bidouillé un peu mais cela ne change pas grand chose.

Voici la commande lancée par l'application C++

xterm -T "Execute Index script" -e "/chemin/vers/index.csh" ; csh -i"

J'ai cherché un peu dans le man de xterm et de csh mais je n'ai rien trouvé. Je n'ai pas vraiment l'habitude de bosser avec ces outils.

  • # rien d'autre apres le git init ?

    Posté par . Évalué à 2.

    il est censé faire quoi apres le git init ?

    s'il n'a rien à faire, ou s'il fait ca tres vite, ton index.csh arrive à la fin, quitte, et ferme le terminal, c'est normal

    ajoute un read ou un sleep à la fin du script, avant de quitter, tu verras si ca marche ou pas.

    • [^] # Re: rien d'autre apres le git init ?

      Posté par (page perso) . Évalué à 2.

      l'ajoute de ceci "csh -i" à la fin de la commande devrait laisser le terminal sur un mode d'attente. De plus, ce qu'il y a après le git init est relativement long (peut aller jusqu'à une nuit de calcul).

      • [^] # Re: rien d'autre apres le git init ?

        Posté par (page perso) . Évalué à 0.

        S'il y en a pour une nuit de calculs, j'aurai tendance à dire que l'utilisateur peut laisser le 'git init' tranquille, même si çà prend 1 heure…

        • [^] # Re: rien d'autre apres le git init ?

          Posté par (page perso) . Évalué à 0.

          Expliquez-lui de quoi vous avez besoin, et Mali vous dira comment vous en passez. :-P

          • [^] # Re: rien d'autre apres le git init ?

            Posté par . Évalué à 2.

            en meme temps il n'a pas tord

            c'est comme si tu voulez sauter une ligne qui fait un simple "echo toto"
            dans un programme qui prend 1 minute.
            ca marche, mais ca n'apporte rien.

            • [^] # Re: rien d'autre apres le git init ?

              Posté par (page perso) . Évalué à 2.

              en meme temps il n'a pas tord

              mais toi, si, tu as tort :p

              It's a fez. I wear a fez now. Fezes are cool !

            • [^] # Re: rien d'autre apres le git init ?

              Posté par (page perso) . Évalué à 1.

              Pas vraiment, je n'ai pas envie d'expliquer le problème en détails mais en gros, le code exécuté après le git init est assez critique donc un utilisateur qui lance le script va attendre de voir le git init finir pour savoir si le reste du traitement va fonctionner. Si le git init met trois plombe, la personne ne sait pas si la suite est bien partie. Si elle revient le matin et que cela n'a pas marcher à cause d'une erreur de syntaxe, elle n'aura pas eu le temps de voir et de corriger le problème (une nuit perdue). Passer le git init permet de gagner du temps.

              Donc, non je ne peux pas dire aux utilisateurs: votre confort d'utilisation, je m'assoie dessus.

              • [^] # Re: rien d'autre apres le git init ?

                Posté par . Évalué à 3.

                si comme tu le disais precedemment, le git init est marginal par rapport au temps de calcul, supprimer/annuler le git init ne changera pas le temps de calcul,
                ton utilisateur n'aura pas plus de retour de l'execution du script s'il faut 8h de calcul.

                et si tu toleres que l'utilisateur fasse Ctrl+C sur le git init, pourquoi ne pas simplement poser la question "souhaitez vous faire un git init ? [O/n]"
                la personne à alors le choix, et tu sais exactement ce qui se passe (et l'utilisateur aussi)

                • [^] # Re: rien d'autre apres le git init ?

                  Posté par (page perso) . Évalué à 1.

                  C'est pas une mauvaise idée, mais je ne suis pas sur que cela passe niveau politique. Mais bon si mes utilisateurs ne regardent pas l’exécution du script cela restera coincé sur le read, donc je ne sais pas trop. Je verrais mais bon il doit bien y avoir moyen de faire ce que je souhaite.

      • [^] # Re: rien d'autre apres le git init ?

        Posté par . Évalué à 2.

        je vais peut être dire une bêtise mais la commande "csh -i" n'est pas exécuter dans xterm… dans ton code.
        En effet, si je lis bien ton truc, tu peux l’écrire également comme suit :

        xterm -T "Execute Index script" -e "/chemin/vers/index.csh"
        csh -i"
        

        Donc le script se contre-fiche du csh -i qui s’exécute une fois que xterm est fini.
        tu devrais essayer de mettre un read à la fin de ton script pour voir.

  • # Exit on error ?

    Posté par . Évalué à 2.

    Est-ce que le script est invoqué avec l'option “exit on error” ? Si c'est le cas, ça expliquerait le comportement que tu vois. En bash, ça se change avec :

    set +e
    

    Mais je ne sais pas pour csh.

  • # Workaround

    Posté par . Évalué à 3.

    Rajoute une option au script pour sauter le git init, et propose 2 lanceurs, un avec et un sans.

  • # Solution

    Posté par (page perso) . Évalué à 2.

    onintr interupt
    git init
    interupt:

    Bon cela permet de catch les interuption et de relancer le script. Du coup, il suffit d'encadrer le git init avec cela.

  • # c'est logique

    Posté par . Évalué à 4. Dernière modification le 14/01/14 à 12:07.

    utiliser un shell pour garder la fenêtre c'es dégelasse

    tu peux gérer ce problème en
    * étant propre et utiliser -hold pour garder la fenêtre ouverte ;) par exemple : \xterm -hold -e ls

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.