J'ai enfin résolu mon problème.
Voici la solution :
Dans Automator, je commence par un shell applescript :
on run argv
set fileName to ""
set locale to user locale of (get system info) & ".UTF-8"
set fileAlias to item 1 of argv as string
if fileAlias is not equal to "" then
set fileName to POSIX path of fileAlias
end if
return locale & "\n" & fileName
end run
Et ensuite un script bash :
IFS="\n" read -r -a array <<< "$@"
locale="${array[0]}"
export LANG=$locale
filename="${array[1]}"
nohup /usr/local/bin/mon_programme $filename >/dev/null 2>&1 &
Et tout fonctionne nickel.
J'utilise comme séparateur le caractère "\n" qui ne peut faire partie ni de la locale ni
d'un nom de fichier. Je découpe ensuite la réponse de l'applescript avec ce séparateur
et récupère ainsi la locale et l'éventuel nom de fichier. J'exécute alors le programme
'/usr/local/bin/mon_programme' avec une syntaxe bizarre ('nohup' + le '&' final) qui permet
de détacher le processus du lanceur Automator qui se termine alors normalement, le
processus du programme tournant alors en tâche de fond.
L'idéal eût été de pouvoir retourner plusieurs argument depuis l'applescript pour les
fournir proprement par $@ au shell, mais je ne sais pas faire (ni ne sais si c'est possible).
On pourrait de la même manière récupérer 'autres infos système (comme le répertoire
utilisateur, par exemple) pour compléter l'initialisation du shell.
C'est un moyen peu cher de simuler une appli OS X depuis un programme ligne de
commande non packagé pour OS X sans avoir à passer par une console et taper du
texte et on peut de plus lier des types de fichiers à cette appli qui est alors ouverte
automatiquement dès que ceux-ci sont double-cliqués dans le Finder. On ne peut
cependant mourir qu'un seul fichier depuis le Finder (mais ça pourrait être résolu
simplement en concaténant les noms de fichier dans une boucle de l'applescript).
En espérant que ça puisse aider quelqu'un un jour, merci à tous ceux qui m'on répondu,
ça m'a bien soutenu.
