#!/usr/bin/env python

# Add for 4 spaces at each line of the current selection
# store the result in the clipboard

import subprocess
import tempfile

sel = subprocess.check_output("xsel")
end_new_line = sel.endswith("\n")
sel = sel.replace("\n", "\n    ", sel.count("\n") - int(end_new_line))
sel = "    " + sel
with tempfile.TemporaryFile() as tmp_file:
    tmp_file.write(sel)
    tmp_file.flush()
    tmp_file.seek(0)
    subprocess.call(["xsel", "-b", "-i"], stdin=tmp_file)

Ça fonctionne toujours mais si j'enlève l'option "-i", ça ne fonctionne plus.

  - essaye laisser le mode par défaut (lecture+ecriture et binaire) sur ton tempfile
  - essaye d'appeler .flush() sur ton file descripteur histoire d'être sûr d'avoir tout est écrit avant de lancer ton process

avec ça ça devrait mieux marcher, tu confirmes ?

En fait non... le code source est très clair: xsel va lire l'entrée standard ssi isatty(0) renvoie True, et après un rapide test chez moi ce n'est pas le cas dans le cas d'un appel depuis subprocess.call() avec l'option stdin settée à un fichier.
D'où l'idée qu'il n'y arrive pas parce que le fichier n'est pas prêt.

En effet c'est bizarre ton histoire, et surtout je n'ai pas le bug chez moi... c'est quoi ta version de python/xsel ?

> python --version && xsel --version
Python 2.7.3
xsel version 1.2.0 by Conrad Parker <conrad@vergenet.net>

OK, ça expliquerait les choses.

Non, je ne crois pas. Voici le code Python de mon petit script:

#!/usr/bin/env python

# Add for 4 spaces at each line of the current selection
# store the result in the clipboard

import subprocess
import tempfile

sel = subprocess.check_output("xsel")
end_new_line = sel.endswith("\n")
sel = sel.replace("\n", "\n    ", sel.count("\n") - int(end_new_line))
sel = "    " + sel
with tempfile.TemporaryFile(mode='w+') as tmp_file:
    tmp_file.write(sel)
    tmp_file.seek(0)
    subprocess.call(["xsel", "-b", "-i"], stdin=tmp_file)

En même temps, l'auteur lui-même précise que son algo de defaulting est assez limite (src) et qu'il vaut mieux utiliser les options explicites comme le -i ici.

Mais bon je suis curieux de voir comprendre le pourquoi du comment. Au hasard, est-tu sûr que ton tmp_file ne vaut pas justement sys.stdin ?

Cela ne me semble pas être en accord avec la doc qui dit:

Ça dit que ça lit l'entrée standard donc je ne vois pas pourquoi je dois employer l'option -i.

cat tmp_file | xsel
xsel <tmp_file
xset -i        # Lecture sur le terminal

mais pas celle-ci :

xsel

Alors effectivement depuis Python, il n'y pas de notion de pipe au sens shell, c'est le call python qui "déverse" le contenu du fichier dans l'entrée de la commande.
Comme si sous shell, on avait fait:

cat tmp_file | xsel

Je ne comprends pas. Si je fais la commande précédente dans le terminal, je n'ai pas besoin de l'option -i comme en Python. Est-ce que ça veut dire qu'il y a une erreur dans la documentation de la commande xsel?

Alors effectivement depuis Python, il n'y pas de notion de pipe au sens shell, c'est le call python qui "déverse" le contenu du fichier dans l'entrée de la commande.
Comme si sous shell, on avait fait:

cat tmp_file | xsel

J'ai de la difficulté à comprendre comment les redirections fonctionnent avec les commandes shell et Python. Par exemple, si dans un shell bash je tape:

aa | bb

Si je tape la commande précédente, cela veut dire que la sortie de la commande 'aa', stdout, sera l'entrée pour la commande 'bb', stdin, n'est-ce pas?

Mon problème se trouve à cette ligne de code en Python :

subprocess.call(["xsel", "-b", "-i"], stdin=tmp_file)

L'entrée pour la commande 'xsel' se trouve avec le fichier tmp_file. Cette commande fonctionne très bien. Ce que je ne comprends pas est que j'ai dû employer l'option '-i' qui est définie dans la doc de xsel de la façon suivante :

 -i, --input           Read standard input into the selection

Ma question est pourquoi dois-je employer cette option?

Par exemple, si je tape dans le shell bash :

echo xx | xsel

xsel lit son information depuis l'entrée standard qui est alimentée par la commande 'echo', n'est-ce pas? Pourquoi n'ai-je pas à employer l'option -i comme pour ma ligne de code Python?