[bash] passage de paramètres à gpodder

Bonjour, pour pallier à l'absence d'itunes du monde linux, j'ai décidé de créer un script qui se déclenche lors d'un clique sur un lien utilisant le protocole itpc:// (qui permet l'abonnement automatique à un flux dans itunes). Le lien est donc transmis à mon script, pour l'instant plutôt rudimentaire, qui doit remplacer itpc:// par http:// pour pouvoir envoyer le lien à gpodder qui l'ajoute automatiquement.
L'objectif de tout ceci est donc de s'abonner à un flux en un click sur un lien itpc:// sans devoir faire un copier/coller
Voici mon script :

itpccatch.sh

Code:

---

1 2 3

#!/bin/bash   gpodder -a http${1#itpc}

---

Le lien est belle et bien rajouter dans gpodder, mais :
- ça ne fonctionne que si gpodder n'est pas déja lancé
- une fois le script terminé gpodder se termine aussi ( je me demande d'ailleurs si l'interface graphique de gpodder se lance, peut être même pas)

Donc je souhaite arriver à transmettre ce lien à gpodder même quand il est lancé (je ne sais même pas par quel bout prendre ce problème)
Et un fois que c'est fait, ouvrir ou laisser ouverte l'interface graphique de gpodder.

Si vous avez des pistes pour réaliser ça, n'hésitez pas!

Merci d'avance

Bonjour,

Citation:

---

ça ne fonctionne que si gpodder n'est pas déja lancé

---

Ca parait logique, puisque ta commande lance gpodder, il y a donc deux instances de gpodder ce qui peut poser problème
Regarde le man de gpodder, peut etre il y a-t-il une option pour intervenir alors qu'il est déjà démarré.

Citation:

---

une fois le script terminé gpodder se termine aussi ( je me demande d'ailleurs si l'interface graphique de gpodder se lance, peut être même pas)

---

Essaye en rajoutant un & à la fin de ta commande.

Cordialement,
Elverion

Bonjour,

Pour passer des informations à une application, il y a plusieurs méthodes:

• Passage d'argument(s) au lancement de l'application.
• Définition de variable(s) globales(s), souvent utilisées au démarrage de l'application.
• Ouverture de socket(s) par l'application pour écouter ce qui pourrait éventuellement lui être envoyé, moyen utilisé en dynamique lorsque l'application est en cours d'utilisation.

Ce dernier moyen est le plus souple, car il peut être utilisé lorsque l'application est déjà démarrée. Il faut cependant savoir si elle a un port ouvert, lequel est-ce, le protocole (tcp ou udp) et la syntaxe utilisée. Ensuite, à partir du shell, il faut envoyer les bonnes données dans le bon tuyaux, en redirigeant la sortie vers le port serveur de l'application:

Code:

---

echo $message > /dev/tcp/localhost/12345

---

Bien bien bien bien bien!

Merci tout d'abord pour vos pistes.

Après une petite enquête, il s'avère que gpodder est écrit en python (langage que je ne connait pas, mais ça n'a pas l'aire d'avoir une syntaxe bien exotique, bref, c'est pas du forth).

Le code révèle que si gpodder est muni d'un quelconque paramètre, celui ci se lancera uniquement en mode console pour donc ce terminer aussitôt une fois son oeuvre terminée.
Si gpodder est executé sans paramètre ou en mode bavard, il se lance en mode graphique.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

if options.maemo: gpodder.interface = gpodder.MAEMO elif options.list or options.run or options.update or \ options.sync or options.add or options.delete: gpodder.interface = gpodder.CLI else: gpodder.interface = gpodder.GUI   if options.verbose: from gpodder.liblogger import enable_verbose enable_verbose()

---

Donc déja, il est clair qu'avec mon

Code:

---

gpodder -a http${1#itpc}

---

de départ, je ne risque pas de voir passer la moindre interface graphique.

On ne peut pas lancer plusieurs instances de gpodder! Non pas qu' une vérification soit opérée dans le code, mais simplement à cause du plantage de la deuxième instance. gpodder utilise en effet une base de données qui se trouve alors verrouillée par la première instance. Si on tente d'en lancer une autre on obtient :

Code:

---

sqlite3.OperationalError: database is locked

---

qui met fin aux hostilités.

Donc dans un premier temps, je peux me contenter de cette solution :

Code:

---

1 2 3 4 5

#!/bin/bash   killall gpodder; gpodder -t -a http${1#itpc} gpodder

---

qui a deux défauts : c'est bien bourrin, et si un téléchargement est en cours il sera interrompu sans possibilité de reprise.

La solution idéale serait donc d'envoyer l'information sur un socket ouvert par l'application ce qui permettrait au script de ne pas avoir à tuer le processus gpodder, mais juste de le lancer au besoin!
Le problème c'est que je connais pas python, et aprés avoir parcouru les divers fichiers, je n'ai vu aucun

Code:

---

import socket

---

qui, d'aprés ce que j'ai compris, est nécessaire pour manipuler ceux-ci (ref:http://docs.python.org/library/socke...socket-example)

Je crois qu'il ne me reste plus qu'à mettre les mains dans le cambouis en essayant de rajouter moi-même ce système d'écoute dans l'application (Oulala, il va falloir que je trouve où mettre le code!!! En python, en plus.)

Merci encore pour votre aide.

ps: le manuel de gpodder qu'il faut aller consulter sur http://www.gopper.org (man gpodder plante) ne donne pas de renseignements sur le sujet.