Forum Programmation.shell CSH : nombre de jobs

Posté par  .
Étiquettes : aucune
0
9
fév.
2009
Bonjour,

J'ai un script en CSH qui lance plusieurs jobs et je souhaiterais mettre en variable le nombre de jobs en cours... Mais je n'y arrive pas !

J'ai essayé différentes façons mais rien n'y fait, il me retourne toujours 0 :
set NBJOBS=`jobs -l | wc -l`
set NBJOBS=`jobs -l |& wc -l`

Exemple bateau de script pour qui veut essayer :
#!/bin/csh
(sleep 300 & sleep 300 & ) >&/dev/null
set NBJOBS=`jobs |& wc -l`
echo "$NBJOBS"
killall sleep

a+

  • # jobs

    Posté par  . Évalué à 5.

    tout simplement parce jobs est relatif au shell courant.
    Enleve tes parentheses (sous shell) et jobs te retounera les sous process
    http://tldp.org/LDP/abs/html/subshells.html

    • [^] # Re: jobs

      Posté par  . Évalué à 1.

      Bon, ça se complique :

      - j'utilisais les parenthèses (dans mon vrai script) afin de rediriger la sortie standard vers un fichier et la sortie erreur vers /dev/null... puisque après quelques recherches, c'est la "solution" la plus propre en csh

      - Pour le problème de départ, il reste identique, je pense que le défaut vient de CSH, je n'ai plus qu'à tout refaire en BASH :
      $ csh
      % sleep 30 & sleep 30 &
      [1] 14419
      [2] 14420
      % jobs -l
      [1] + 14419 Running sleep 30
      [2] - 14420 Running sleep 30
      % jobs -l | wc -l
      0
      % jobs -l
      [1] + 14419 Running sleep 30
      [2] - 14420 Running sleep 30
      %

      Merci quand même.

      • [^] # Re: jobs

        Posté par  . Évalué à 2.

        2 process dans un sous process écriront pas plus dans l'ordre sur stdout que 2 process en fond appelés séquentiellement.
        Ca peut donc se réécrire:

        #!/bin/csh
        sleep 300 2>/dev/null &
        sleep 300 2>/dev/null &
        set NBJOBS=`jobs |& wc -l`
        echo "$NBJOBS"
        killall sleep

        • [^] # Re: jobs

          Posté par  . Évalué à 1.

          Cette solution ne marche pas non plus et est plus embettante pour moi :
          - La redirection de stderr vers /dev/null ne fonctionne pas. Ta solution est valable en bash, pas en csh (je sais csh ça ne roxe pas, mais je dois faire avec !)
          - C'est expliqué plus bas : jobs n'écrit pas sur la sortie standard en csh, il est donc impossible de faire un pipe à la suite pour en traiter les info.

          Merci tout de même pour l'intérêt que tu portes à mon problème (je n'ai généralement que des problèmes insolvables, ça en devient pénible...)

          • [^] # Re: jobs

            Posté par  . Évalué à 2.


            set a =`ps --ppid $$ | wc -l`
            @a-=2

  • # Il faut écrire des scripts bourne

    Posté par  (site web personnel) . Évalué à 3.

    Il vaut mieux utiliser sh que csh pour les scripts :
    http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

  • # csh considered harmful

    Posté par  . Évalué à 4.

    Il me semble que j'etais tombé sur le meme os en voulant aidé un ami egaré sous tcsh :)
    En regardant de plus pres, j'ai l'impression que le probleme vient en effet de csh :
    la commande jobs n'ecrit pas sur les descripteurs standards stdout et stderr, mais semble etre affiché "directement" sur le tty. Et donc n'est pas recuperable dans un pipe.

    exemple : (tcsh)

    [user@host ~]$ jobs
    [1] + Running xclock
    [user@host ~]$ jobs | grep xclock
    [user@host ~]$ jobs |& grep xclock

    Les deux commandes renvoient ... rien !

    Solutions :

    1) UTILISER UN SHELL TYPE SH !!!!
    2) tricher en recuperant la liste des jobs sans la commande jobs : pgrep -P $$
    soit : recuperer la liste des processus dont le parent a le PID du shell.

    PS : pour info, la commande jobs de bash affiche sur stdout

    • [^] # Re: csh considered harmful

      Posté par  . Évalué à 1.

      Super, merci pour cette réponse très claire et pour le contournement bien pratique dans l'immediat. Mais je vais tout de même me mettre au bash, ça simplifiera les choses dans l'avenir.

Suivre le flux des commentaires

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