web-dev-qa-db-fra.com

Commande montrant un comportement différent lors de l'exécution à partir du terminal et lors de l'utilisation en tant que raccourci

J'utilise KUbuntu 18.04.1

J'essaie d'extraire le texte d'une capture d'écran à l'aide de spectacle (application de capture d'écran de KUbuntu) et gocr (outil OCR)

Si je donne les commandes les unes après les autres à Konsole (Terminal de KUbuntu)

D'abord: 

spectacle -r -b -n -o /home/UserName/Documents/Translate/input.jpg

Deuxième: 

gocr -i /home/UserName/Documents/Translate/input.jpg | xsel -b

Ça marche.

si je crée un fichier bash screen_ts.sh et que je mets le code

#!/bin/bash
# Dependencies: gocr xsel

# Take Screenshot and Save it to a File
spectacle -r -b -n -o /home/UserName/Documents/Translate/input.jpg

# Extract text from the saved file
gocr -i /home/UserName/Documents/Translate/input.jpg | xsel -b

exit

Ouvrez Konsole et tapez ./Screen_ts.sh, ça marche

Mais, si je Rends le fichier exécutable et double-cliquez, cela prendra une capture d'écran mais n'enregistrera pas le texte dans le presse-papiers.

Encore une fois, si je crée un raccourci personnalisé en utilisant

Raccourci personnalisé> Déclencheur Alt + Q & Action /home/UserName/Documents/Translate/screen_ts.sh

KUbuntu Custom Shortcut

il prend une capture d'écran mais n'enregistre pas le texte dans le presse-papiers. Même comportement qu'un double clic.

Qu'est-ce qui se passe ici?

command-linebashkubuntushortcut-keyskde
2
blueray

De man xsel :

Par défaut, ce programme sort la sélection sans modification si l'entrée standard et la sortie standard sont des bornes (ttys). Sinon, la sélection actuelle est sortie si la sortie standard n'est pas une borne (tty), et la sélection est définie à partir de l'entrée standard si l'entrée standard n'est pas une borne (tty). Si des options d'entrée ou de sortie sont données, le programme se comporte uniquement dans le mode demandé.

C'est un peu trompeur, mais il y a un commentaire intéressant dans le code source :

Vérifier que stdin/stdout n'est pas un tty n'est pas fiable pour dire ce que veut l'utilisateur. En effet, les processus enfants héritent des descripteurs de fichiers de leurs parents; un xsel appelé dans un script qui est par exemple démonisé (non attaché à un tty), ou appelé avec une redirection ou dans un pipeline aura des descripteurs de fichier non tty par défaut. Le problème de redirection/canalisation s'applique également aux commandes "groupées" ou "composées" dans le shell (fonctions, sous-coques, blocs à accolade, conditionnelles, boucles, etc.). Dans tous ces cas, l'utilisateur doit définir explicitement le mode de fonctionnement.

... et c'est la solution: dites à xsel de lire explicitement à partir de stdin en ajoutant le -i option:

gocr -i /home/UserName/Documents/Translate/input.jpg | xsel -b -i
2
danzel