Re: Warning avec compilation au terminal sur la 2.23.82 sous macos

[Eulogia]

Bonjour JM, 

Dans ma situation, cela n'a rien à voir avec le shell, puisque c'est le même 
shell (zsh) avec le même fichier de configuration, qui sont lancés dans les 
deux cas. 

Le problème vient plutôt du fait que macos permet de lancer une application 
dans une autre langue que celle du système, il y a donc forcément une gestion 
régionale à chaque lancement d'application, terminal compris.


J'ai fait encore quelques tests, qui sont d'ouvrir le terminal depuis un 
Applescript, et là, cela fonctionne! Cela veut donc dire que c'est lorsque je 
lance l'Applescript depuis le fragment Python de Frescobaldi que, soit le 
terminal récupère l'encoding de python pour ce paramètre, soit il met la valeur 
par défaut, ne sachant pas comment l'initialiser. 

Et l'instruction python ne permet de définir qu'un encoding='utf-8' et pas ceux 
proposés par Jean, je suppose donc que le problème vient de là. 


Au plaisir, 

ben


> Le 9 déc. 2022 à 14:45, Jacques Menu <imj-muzhic@bluewin.ch> a écrit :
> 
> Bonjour Ben,
> 
> Est-ce une différence entre un shell interactif et un autre, en termes 
> d’initialisation de l’environnement?
> 
> JM
> 
>> Le 9 déc. 2022 à 14:25, Eulogia <eulogia@eulogia.ch> a écrit :
>> 
>> Bonjour, 
>> 
>> Alors, j'ai refait toute une série de tests et j'ai trouvé!
>> 
>> 
>> En fait, c'est la manière dont l'application terminal est lancée qui pose le 
>> problème. 
>> 
>> Dès lors que l'application terminal est lancée normalement par un click dans 
>> le dock, dans le finder ou via spotlight, tout fonctionne sans warning, même 
>> en passant par l'Applescript, par python3 ou directement par lilypond, etc. 
>> 
>> Mais dès lors, que l'Applescript détecte que le terminal n'est pas lancé, et 
>> qu'il se charge lui-même de le lancer, le warning apparaitra 
>> systématiquement, peu importe que je passe ensuite par l'Applescript, 
>> python3 ou directement lilypond.
>> 
>> 
>> Et si j'utilise l'instruction 'open -a Terminal', j'ai le même problème que 
>> quand le terminal est lancé par l'Applescript.
>> 
>> J'ai bien essayé de jouer avec l'option "encoding" de l'instruction python 
>> check_output, mais cela ne change rien.
>> 
>> Donc en attendant, la meilleure solution est bien de lancer FC_LANG=C 
>> lilypond, et peu importe comment le terminal est lancé, cela fonctionne. 
>> 
>> 
>> Merci pour toutes vos suggestions. 
>> 
>> Au plaisir, 
>> 
>> ben 
>> 
>> 
>> 
>>> Le 9 déc. 2022 à 13:18, Jean Abou Samra <jean@abou-samra.fr> a écrit :
>>> 
>>> Le 08/12/2022 à 17:44, Eulogia a écrit :
>>>> D'accord merci!
>>>> 
>>>> Je ne sais pas trop à quoi cela correspond, ni pourquoi le problème ne se 
>>>> pose que sur certains fichiers, mais ce n'est pas très grave.
>>> 
>>> 
>>> 
>>> Je n'ai pas compris non plus dans quelles conditions le problème
>>> arrivait pour vous. A priori, c'est étrange que cela ne se produise
>>> que sur certains fichiers étant donné que les paramètres de
>>> langue sont externes à LilyPond. Vous êtes sûr qu'il n'y a pas
>>> quelque chose de différent dans la façon dont vous compilez
>>> ces fichiers ? Les détails ont leur importance, par exemple
>>> l'application de terminal utilisée (terminal normal ou via
>>> Applescript ?), ou le type de shell (bash ou zsh, voire autre
>>> chose).
>>> 
>>> LC_CTYPE est l'une des variables d'environnement qui contrôlent
>>> la langue. Elle agit sur la conversion des caractères et ce
>>> genre de choses (par exemple la conversion entre majuscules
>>> et minuscules). À ce que j'ai compris, dans certaines situations,
>>> macOS règle LC_CTYPE à "UTF-8". Techniquement parlant, c'est
>>> conforme au standard POSIX, qui dit que le système a le droit
>>> de définir les valeurs qu'il veut, mais en pratique, ce n'est
>>> pas une valeur à laquelle on s'attendrait (plutôt "C.UTF-8"
>>> ou "en_US.UTF-8"), d'où le problème...
>>> 
>>> Cordialement,
>>> Jean
>>> 
>> 
>> 
>