Sur quelle touche appuyez-vous? Retour arrière?

Si cela est vrai, exécutez bind -k backspace pour savoir à quoi il est défini, puis exécutez par exemple script (ou bash et appuyez sur ctrl + v) et appuyez sur la touche pour savoir quelle séquence ça envoie. (Le script placera par défaut la totalité de la sortie de cette session dans un fichier appelé "typographie" dans le répertoire courant). Xterm devrait envoyer "\ cH", quel poisson devrait (via terminfo, qui _nécessite_ $ TERM pour être défini correctement) comme retour arrière.

Les futures versions de fish rendront cela un peu plus facile avec un petit programme d'aide appelé "fish_key_reader".

À quoi votre $ TERM est-il défini? "xterm"?

la clé est Backspace.
s'il vous plaît envoyez-moi un maill, et je vous donnerai accès à ma boîte, vous laisser découvrir la raison.

la clé est Backspace.

L'étiquette sur la touche ne nous dit pas quelle séquence de caractères elle envoie. Pouvez-vous installer des poissons à partir de sources tirées du référentiel git? Si vous pouvez alors make fish_key_reader suivi de ./fish_key_reader puis appuyez sur la touche de retour arrière. Si vous ne pouvez pas exécuter xxd ou od -tx1z puis appuyez sur la touche de retour arrière suivie de [ctrl-D]. Exécutez également bind -k backspace et montrez-nous cette sortie. Exécutez également echo $TERM .

Nous préférerions ne pas nous connecter à votre système à la fois pour des raisons de responsabilité et parce que nous ne lisons pas le chinois, il nous sera donc difficile de travailler avec set LANG zh_CN.UTF-8 .

./fish_key_reader
999999 usec dec: 8 hex: 8 car: \ b (aka \ cH)
Pour info: séquence de scie pour le nom de la touche de liaison "retour arrière"

bind -k retour arrière
bind: aucune liaison trouvée pour la clé «retour arrière»

echo $ TERM
xterm

bind: aucune liaison trouvée pour la clé «retour arrière»

D'accord, c'est votre problème. Cela devrait dire quelque chose comme

bind -k backspace backward-delete-char

Je ne vois pas comment cela pourrait avoir quelque chose à voir avec la définition de la variable LANG. Vous avez en quelque sorte remplacé les raccourcis clavier par défaut. Je chercherais dans vos fichiers _ ~ / .config / fish / _ ** les mentions du mot "bind". De plus, utilisez-vous des gestionnaires de plugins (par exemple, fisherman ou oh-my-fish) ou avez-vous installé d'autres scripts tiers qui pourraient être pertinents pour ce problème?

D'ACCORD.
les ~ / .config / fish / n'ont que 3 fichiers: config.fish fish_history fishd.lhmtestdf.com

cat config.fish
set LANG zh_CN.UTF-8

cat fishd.lhmtestdf.com 
# This file is automatically generated by the fish.
# Do NOT edit it directly, your changes will be overwritten.
SET __fish_init_1_50_0:\x1d
SET __fish_init_2_3_0:\x1d
SET fish_color_autosuggestion:555\x1eyellow
SET fish_color_command:005fd7\x1epurple
SET fish_color_comment:red
SET fish_color_cwd:green
SET fish_color_cwd_root:red
SET fish_color_end:green
SET fish_color_error:red\x1e\x2d\x2dbold
SET fish_color_escape:cyan
SET fish_color_history_current:cyan
SET fish_color_host:normal
SET fish_color_match:cyan
SET fish_color_normal:normal
SET fish_color_operator:cyan
SET fish_color_param:00afff\x1ecyan
SET fish_color_quote:brown
SET fish_color_redirection:normal
SET fish_color_search_match:\x2d\x2dbackground\x3dpurple
SET fish_color_selection:\x2d\x2dbackground\x3dpurple
SET fish_color_user:green
SET fish_color_valid_path:\x2d\x2dunderline
SET fish_greeting:Welcome\x20to\x20fish\x2c\x20the\x20friendly\x20interactive\x20shell\x0aType\x20\x1b\x5b32mhelp\x1b\x5b30m\x1b\x28B\x1b\x5bm\x20for\x20instructions\x20on\x20how\x20to\x20use\x20fish
SET fish_key_bindings:fish_default_key_bindings
SET fish_pager_color_completion:normal
SET fish_pager_color_description:555\x1eyellow
SET fish_pager_color_prefix:cyan
SET fish_pager_color_progress:cyan

sous poisson-2.2.0
la commande bind ouput:

bind
bind '' self-insert
bind \n execute
bind \ck kill-line
bind \cy yank
bind \t complete
bind \e\n commandline\ -i\ \\n
bind \e\[A up-or-search
bind \e\[B down-or-search
bind -k down down-or-search
bind -k up up-or-search
bind \e\[C forward-char
bind \e\[D backward-char
bind -k right forward-char
bind -k left backward-char
bind -k dc delete-char
bind -k backspace backward-delete-char
bind backward-delete-char
bind \e\[H beginning-of-line
bind \e\[F end-of-line
bind \e\[1\~ beginning-of-line
bind \e\[4\~ end-of-line
bind -k home beginning-of-line
bind -k end end-of-line
bind -k sdc backward-delete-char
bind \e\eOC nextd-or-forward-word
bind \e\eOD prevd-or-backward-word
bind \e\e\[C nextd-or-forward-word
bind \e\e\[D prevd-or-backward-word
bind \eO3C nextd-or-forward-word
bind \eO3D prevd-or-backward-word
bind \e\[3C nextd-or-forward-word
bind \e\[3D prevd-or-backward-word
bind \e\[1\;3C nextd-or-forward-word
bind \e\[1\;3D prevd-or-backward-word
bind \e\eOA history-token-search-backward
bind \e\eOB history-token-search-forward
bind \e\e\[A history-token-search-backward
bind \e\e\[B history-token-search-forward
bind \eO3A history-token-search-backward
bind \eO3B history-token-search-forward
bind \e\[3A history-token-search-backward
bind \e\[3B history-token-search-forward
bind \e\[1\;3A history-token-search-backward
bind \e\[1\;3B history-token-search-forward
bind \ca beginning-of-line
bind \ce end-of-line
bind \ey yank-pop
bind \cw backward-kill-path-component
bind \cp history-search-backward
bind \cn history-search-forward
bind \cf forward-char
bind \cb backward-char
bind \ct transpose-chars
bind \et transpose-words
bind \eu upcase-word
bind \ec capitalize-word
bind \ backward-kill-word
bind \eb backward-word
bind \ef forward-word
bind \e\[1\;5C forward-word
bind \e\[1\;5D backward-word
bind \e\[1\;9A history-token-search-backward
bind \e\[1\;9B history-token-search-forward
bind \e\[1\;9C forward-word
bind \e\[1\;9D backward-word
bind \e. history-token-search-backward
bind -k ppage beginning-of-history
bind -k npage end-of-history
bind \e\< beginning-of-buffer
bind \e\> end-of-buffer
bind \el __fish_list_current_token
bind \ew 'set tok (commandline -pt); if test $tok[1]; echo; whatis $tok[1]; commandline -f repaint; end'
bind \cl 'clear; commandline -f repaint'
bind \cc 'commandline ""'
bind \cu backward-kill-line
bind \ed kill-word
bind \cd delete-or-exit
bind -k f1 __fish_man_page
bind \eh __fish_man_page
bind \ep __fish_paginate
bind -k btab complete-and-search
bind \e cancel
bind \e\[I 'begin;end'
bind \e\[O 'begin;end'

mais sous fish-2.3.0, la commande lie la sortie:

bind
bind '' self-insert
bind \n execute
bind \r execute
bind \t complete
bind \cc 'commandline ""'
bind \cd exit
bind \ce bind

Comment avez-vous installé fish 2.3.0? Il semble que vous exécutiez un binaire fish qui ne trouve pas ses scripts d'espace utilisateur.

de la source

git clone
autoconf
configure
gmake
gmake install

D'accord, cela semble raisonnable. Que produisent les commandes suivantes:

echo $__fish_active_key_bindings
echo $fish_function_path

Y a-t-il un _fish_default_key_bindings.fish_ dans l'un des répertoires de chemin de fonction (généralement le dernier répertorié)? Je suis curieux de savoir ce que functions fish_default_key_bindings produit. Ne copiez pas cette sortie, mais elle doit correspondre à ce qui se trouve dans le fichier _fish_default_key_bindings.fish_. De plus, les raccourcis clavier sont normalement configurés par le script ___ fish_config_interactive.fish_ qui doit se trouver dans l'un des répertoires répertoriés par le chemin de la fonction var.

quand je supprime .config / fish / config.fish, tout fonctionne bien.
mais quand je mets la chaîne set LANG zh_CN.UTF-8 dans .config / fish / config.fish ou /usr/local/etc/fish/config.fish, le problème survient.

echo $__fish_active_key_bindings ne produit rien.

echo $fish_function_path sorties:
/home/lhm/.config/fish/functions /usr/local/etc/fish/functions /usr/local/share/fish/vendor_functions.d /usr/local/share/fish/functions

quand je supprime .config / fish / config.fish ou commente toutes les lignes dans /usr/local/etc/fish/config.fish, les résultats sont:

echo $__fish_active_key_bindings sortie:
fish_default_key_bindings

echo $fish_function_path sortie:
/home/lhm/.config/fish/functions /usr/local/etc/fish/functions /usr/local/share/fish/vendor_functions.d /usr/local/share/fish/functions

le fichier fish_default_key_bindings.fish trouve dans /usr/local/share/fish/functions/fish_default_key_bindings.fish

Il semble que les poissons ne définissent jamais les raccourcis clavier.

C'est soit parce que __fish_config_interactive (qui inclut la configuration de la liaison) n'est jamais exécuté (ce qui devrait être juste avant votre première invite) ou parce que votre $ fish_key_bindings est vide (nous devrions probablement revenir aux liaisons par défaut si la valeur est pas valide).

Puisqu'il semble être déclenché en définissant $ LANG, cela indique un problème d'encodage.

Tous vos fichiers de configuration et le fichier fishd pourraient être beaux dans une forme vierge car je ne suis pas sûr que github essaie utilement de corriger l'encodage. De plus, quelle est votre valeur $ LANG si vous ne la définissez pas dans config.fish? (Il devrait être compatible ASCII, sinon je ne pense pas que nous pourrions même lire nos propres fichiers, mais on ne sait jamais)

J'ai ajouté set LANG zh_CN.UTF-8 à mon _config.fish_ et je n'ai rencontré aucun problème. Comme le dit @faho , cela semble être un problème d'encodage de caractères. Plus précisément, vos fichiers fish ne sont pas encodés en UTF-8. Que rapporte file /usr/local/share/fish/functions/__fish_config_interactive.fish ? S'il dit "texte ASCII", ajoutez votre ligne LANG puis démarrez un nouveau shell comme celui-ci pour collecter la sortie de débogage:

script
fish -d5
exit
exit

Ensuite, attachez le fichier _typescript_ à ce problème.

file /usr/local/share/fish/functions/__fish_config_interactive.fish
/usr/local/share/fish/functions/__fish_config_interactive.fish: ASCII text

cat typescript output:
Script started on Mon May 23 07:34:02 2016
@ ~/home/lhm> /usr/local/bin/fish -d5
@ ~/home/lhm> exit

@ ~/home/lhm> exit

Que se passe-t-il? Vous dites que fish -d5 n'a produit aucune sortie autre qu'une invite du shell? Vous devriez avoir obtenu une tonne de sortie qui ressemble à ce qui suit:

fish: Continue job 1, gid 0 (fish_title), COMPLETED, NON-INTERACTIVE
fish: proc::read_try('fish_title')
fish: io_buffer_t::read: blocking read on fd 3

Est-ce que DragonFly fait référence à https://www.dragonflybsd.org/? Je me demande si ce texte sur cette page Web, "un nouveau système de paramètres régionaux", est pertinent. Avez-vous construit des poissons à partir de git head sur ce système? Sinon, d'où vient le binaire de poisson? Que se passe-t-il si vous à la place set LANG C ou set LANG en_US.UTF-8 .

oui, https://www.dragonflybsd.org/ est la page d'accueil du projet.
Je construis à partir de git source comme:

git clone
autoconf
configure
gmake
gmake install

seul le jeu LANG C peut créer des sorties de travail fish -d5 comme:

<2> fish: sourcing /usr/local/share/fish/config.fish
<4> fish: Exec job 'builtin source /usr/local/share/fish/config.fish' with id 1
<4> fish: Exec job 'set -g IFS \n\ \t' with id 2
<3> fish: Skipping fork: no output for internal builtin 'set'
<3> fish: Set status of set -g IFS \n\ \t to 0 using short circuit
<3> fish: Job is constructed
<4> fish: Continue job 2, gid 0 (set -g IFS \n\ \t), COMPLETED, NON-INTERACTIVE
<4> fish: Exec job 'status --is-interactive' with id 2
<3> fish: Skipping fork: no output for internal builtin 'status'
<3> fish: Set status of status --is-interactive to 0 using short circuit
<3> fish: Job is constructed
<4> fish: Continue job 2, gid 0 (status --is-interactive), COMPLETED, NON-INTERACTIVE
<4> fish: Exec job 'not set -q NVIM_LISTEN_ADDRESS' with id 2
<3> fish: Skipping fork: no output for internal builtin 'set'
<3> fish: Set status of not set -q NVIM_LISTEN_ADDRESS to 1 using short circuit
<3> fish: Job is constructed
<4> fish: Continue job 2, gid 0 (not set -q NVIM_LISTEN_ADDRESS), COMPLETED, NON-INTERACTIV

set LANG en_US.UTF-8 est le même résultat que set LANG zh_CN.UTF-8 , n'a produit aucune sortie autre qu'une invite du shell.

sur une autre boîte DF 4.4

/usr/local/bin/fish -d5
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings

fish-2.2.0 fonctionne correctement.

D'accord, il y a clairement une incompatibilité entre les fonctions fish et les fonctions larges de DragonFly ou un bug dans ces dernières. Avez-vous accès à un système DragonFly 4.3 sur lequel vous pouvez construire et tester des poissons? Ce serait bien si nous pouvions commencer par confirmer que ce sont les changements introduits dans la prise en charge des paramètres régionaux de DragonFly 4.4 qui sont le changement clé.

J'ai testé le dernier poisson sur une boîte DragonFly 4.2-RELEASE, tout fonctionne bien.

cat .config/fish/config.fish 
set -gx LANG zh_CN.UTF-8

locale
LANG="zh_CN.UTF-8"
LC_CTYPE="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_ALL=""


/usr/local/bin/fish -v
fish, version 2.3.0-162-g85e701f

uname -a
DragonFly . 4.2-RELEASE DragonFly v4.2.4-RELEASE #6: Sun Aug  9 13:25:14 EDT 2015     [email protected]:/usr/obj/home/justin/release/4_2/sys/X86_64_GENERIC  x86_64

D'accord, veuillez parler aux responsables de DragonFly. Je ne dis pas que la faute réside dans leur code. Mais ils sont plus susceptibles d'expliquer pourquoi des fonctions comme mbrtowc() et wcrtomb() ne donnent pas le résultat attendu lorsque le poisson les appelle. Il est très peu probable que ce comportement affecte uniquement les poissons.

Je peux également reproduire ceci sur DragonFly BSD 4.5-DEVELOPMENT, avec n'importe quelle locale UTF-8 (par exemple en_AU.UTF-8 ).

@ krader1961
Alors, pourriez-vous me donner un cas de test pour tester les fonctions mbrtowc () et wcrtomb ()?

D'accord, veuillez parler aux responsables de DragonFly. Je ne dis pas que la faute réside dans leur code. Mais ils ont plus de chances d'expliquer pourquoi des fonctions comme mbrtowc () et wcrtomb () ne donnent pas le résultat attendu lorsque fish les appelle. Il est très peu probable que ce comportement affecte uniquement les poissons.

Alors, pourriez-vous me donner un cas de test pour tester les fonctions mbrtowc () et wcrtomb ()?

J'allais suggérer

$ gmake fish_tests
$ ./fish_tests convert

Mais cela n'échoue pas. L'exécution de tous les tests via ./fish_tests échoue à plusieurs tests, mais rien n'explique ce problème.

J'ai installé DragonFly 4.4.3 et construit et installé fish à partir de git head. Commencer le poisson avec set -x LANG en_US.UTF-8 dans mon _config.fish_ a produit beaucoup d'erreurs inattendues telles que

alias: Name cannot be empty
There is no fish_key_bindings function called: 'fish_default_key_bindings'
Reverting to default bindings

Sans surprise, bind montré très peu de raccourcis clavier car les liaisons par défaut sont minimes. La commande locale signalé C jusqu'à ce que je le définisse explicitement sur en_US.UTF-8 . Le premier fonctionne alors que le second ne fonctionne pas. Le fait que la locale par défaut du système soit "C" plutôt que "en_US.UTF-8" est surprenant. Cela indique-t-il que les développeurs DragonFly reconnaissent que leur support UTF-8 a des problèmes?

Je peux ou non passer plus de temps à déboguer cela. Je vous encourage à parler aux responsables de DragonFly car ils seront probablement en mesure de vous donner un aperçu de ce problème.

J'ai un cas de test assez minimal avec fwprintf , donc je vais demander les types BSD DragonFly.

Je serais heureux de tester n'importe quel patch.

Sur la liste de diffusion DragonFly BSD, Romick dit :

J'ai regardé l'analyseur dans fish-shell, vous utilisez des caractères spéciaux directement dans le flux d'entrée pour marquer différentes choses, telles que BRACKET_BEGIN, BRACKET_END, BRACKET_SEP, INTERNAL_SEPARATOR et ainsi de suite.

Cela fonctionne jusqu'à ce que vous ayez rencontré les paramètres régionaux dans lesquels les caractères sont des membres à part entière de l'alphabet.
Vous voyez, la plage Unicode est de 0x0 à 0x10FFFF et le caractère INTERNAL_SEPARATOR a un code de 0xFDD7.

Dans DragonFly BSD, la fonction iswalnum () vérifie toutes les locales simultanément, donc
que vous avez trois choix:
1) utilisez votre propre iswalnum ():

diff --git a/src/common.h b/src/common.h
index e59dfc0..e8c01c3 100644
--- a/src/common.h
+++ b/src/common.h
@@ -769,4 +769,8 @@ __attribute__((noinline)) void debug_thread_error(void);
 /// specified base, return -1.
 long convert_digit(wchar_t d, int base);

+inline int iswalnum(wchar_t chr) {
+ return((chr >= L'a' && chr <= L'z') || (chr >= L'A' && chr <= L'Z') || iswdigit(chr));
+}
+
 #endif

2) utilisez des valeurs plus grandes pour vos caractères spéciaux (je n'ai pas testé cela).

3) autre chose :)

Je me demande si cet individu sait quelque chose sur Unicode. Ces "caractères spéciaux" sont des caractères de zone d'utilisation privée qui sont définis comme n'étant pas des alphanums: https://en.wikipedia.org/wiki/Unicode_character_property#General_Category. J'ai testé cela sur OS X, Linux et DragonFly. Et, bien sûr, tous les trois renvoient false pour iswalnum(INTERNAL_SEPARATOR) . De plus, nous ne transmettons jamais ces caractères spéciaux à des fonctions comme fwprintf (), donc je ne vois pas pourquoi c'est même pertinent.

Vraiment beau cas de test réduit @zanchey!

Comment installez-vous DragonflyBSD? J'ai essayé avec une ISO nocturne et également la version 4.4.3 ISO (en utilisant Virtualbox) et je n'ai pas pu reproduire le problème avec le cas de test réduit fwprintf.

edit: J'ai également pu construire et installer fish sur 4.4.3, et les tests réussissent aussi, à l'exception des tests notifier.

Le scénario de test échoue uniquement sur SSH - il fonctionne sur la console système dans VirtualBox.

Oh wow. Utilisez-vous Vagrant?

Non, tout simplement VirtualBox 5.0.20.

Je vais m'en occuper après avoir fermé le # 3406 en double. J'essaierai de trouver le temps d'installer FreeBSD et de reproduire le problème et, en cas de succès, de le déboguer davantage.

@lhmwzy, c'est probablement le même problème que # 3406. Pour votre information, j'ai divisé ce dernier problème en deux et l'ai retrouvé pour commettre f2246dfb343bea19beb176fb2cc534f85513b2eb.

De ma mise à jour au numéro 3406 (notez que je travaille maintenant avec FreeBSD 12 plutôt que DragonFly BSD):

Pour info, j'ai installé FreeBSD 12 et je peux reproduire ce problème. La raison pour laquelle aucune des clés ne fonctionne est que les raccourcis clavier par défaut ne sont pas configurés dans un environnement local UTF-8:

Reverting to default bindings
The function call stack limit has been exceeded. Do you have an accidental infinite loop?
fish: __fish_reload_key_bindings VARIABLE SET fish_key_bindings
      ^
in event handler: handler for variable 'fish_key_bindings'

Il existe également d'autres erreurs telles que alias: Name cannot be empty . J'ai également confirmé que la construction de git checkout f2246df~ ne présentait pas le problème. Ce qui est très surprenant pour moi en tant qu'auteur de ce changement.

Bon travail pour trouver le commit où le comportement a divergé. Je ne vois pas ce qui ne va pas avec cela, cependant.

Il existe également d'autres erreurs telles que l'alias: le nom ne peut pas être vide

@ krader1961 : Cela semble être le même problème @floam saw: les guillemets contenant uniquement des variables se résolvent en un argument vide - cette erreur est émise lorsque l'alias échoue test -z "$name" .

@faho , Oui, j'étais juste en train de déboguer cet échec de la fonction d'alias et suis arrivé à la même conclusion. Que cela explique tous ces symptômes BSD ou non, cela semble être un bon endroit pour creuser plus profondément car les chaînes entre guillemets impliquent l'un de nos jetons internes, VARIABLE_EXPAND_SINGLE, qui se trouve dans la plage de caractères réservés unicode.

De plus, j'ai ajouté des instructions de débogage et toutes les fonctions isw...() nous utilisons (par exemple, iswalnum() ) renvoient le résultat correct pour ces jetons internes sur FreeBSD 12. Donc, la suggestion donnée à @zanchey par quelqu'un sur une liste de diffusion BSD pour définir notre propre iswalnum est inutile.

En fait, vous pouvez reproduire assez facilement l'extension var à l'intérieur d'un problème de chaîne entre guillemets avec une locale UTF-8 sur BSD:

$ set wtf b
$ echo a "$wtf" c
a  c
$ echo "a $wtf c"
a b c
$ echo "a $wtf"
a
$ echo "$wtf c"
b c

Cela vaut vraiment la peine d'approfondir ce qui se passe lors de la fin d'une référence var avec un guillemet double. Tous les exemples ci-dessus fonctionnent correctement avec LC_ALL = C.

J'avais tort quand j'ai dit il y a quelques heures que iswalnum() retournait la bonne réponse sur FreeBSD. J'ai appelé par erreur cette fonction dans ma sortie de débogage avant que setlocale("") ne soit appelé. Le déplacement de ces impressions de débogage montre que le bloc de 32 points de code commençant à 0xFDD0 fait que iswalnum() et iswgraph() retournent un plutôt que la valeur correcte, zéro, sur FreeBSD mais pas GNU. D'un autre côté, GNU renvoie incorrectement un pour iswgraph() pour les caractères à usage privé commençant à 0xF600 que nous utilisons alors que FreeBSD renvoie correctement zéro.

Il semble donc que nous devions implémenter nos propres wrappers autour de ces fonctions pour obtenir un comportement correct quelle que soit la plate-forme. Je dois réfléchir un peu à la manière de le faire avec le minimum de code supplémentaire et des couches d'abstraction déroutantes.

J'ai ouvert ce bogue FreeBSD . Nous aurons toujours besoin de contourner cette implémentation cassée.

Nous avons déjà établi le modèle selon lequel le code de poisson devrait appeler fish_wcswidth() plutôt que wcswidth() . Nous avons inscrit cela en tant que règle cppcheck (voir _.cppcheck.rule_). On pourrait faire la même chose pour la famille de fonctions isw...() . Mais est-ce la meilleure solution? C'est certainement le plus simple à mettre en œuvre. Quelqu'un at-il une meilleure solution?

PS, je suis enclin à classer ce problème comme une "amélioration" plutôt que comme un "bug" parce que nous parlons d'améliorer les poissons pour contourner un bogue dans l'une des plates-formes que nous supportons. Oui? Non? On s'en fout? :sourire:

PPS, j'ai vérifié que le remplacement de la plate-forme fournie par iswalnum() corrige ce problème sur FreeBSD 12.

Ma façon préférée de gérer cela serait de vérifier le comportement au moment de la configuration et de remplacer les fonctions si et seulement si elles sont incompatibles à cet égard.

Je ne vais pas baser le remplacement des fonctions de la plate-forme sur des tests autoconf. Tout d'abord, nous avons vu des instances de distributions qui ont un comportement correct (ou incorrect) dans une version, puis inversé le comportement dans une version ultérieure. Un binaire construit pour FreeBSD 10, par exemple, devrait toujours fonctionner correctement sur FreeBSD 12. Baser notre comportement sur un test autoconf ne gère pas cela. Deuxièmement, les tests en question sont extrêmement bon marché même si nous les enveloppons pour garantir un comportement correct et que les appels aux fonctions affectées ne sont pas dans des boucles de performances critiques. Troisièmement, nous avons besoin de l'une des fonctions d'assistance que ce changement introduira pour nous assurer que nous ne permettons pas aux utilisateurs d'injecter notre utilisation interne magique uniquement des points de code (qui se trouvent sur ma liste TODO) dans notre état interne.

De plus, pour mémoire, lorsque j'ai écrit la déclaration suivante dans un commentaire précédent, les deux distributions ont été inversées:

D'un autre côté, GNU renvoie incorrectement un pour iswgraph () pour les caractères à usage privé commençant à 0xF600 que nous utilisons alors que FreeBSD renvoie correctement zéro.

Selon la FAQ Unicode, les points de code dans les zones d'utilisation privée sont destinés à être classés comme ayant un glyphe associé (c'est-à-dire que iswgraph() doit en renvoyer un) mais ne sont pas alphanumériques (c'est-à-dire que iswalnum() doit renvoyer zéro).

Il me semble qu'un test autoconf vérifiant le résultat de iswalnum () sur l'une de ces valeurs fonctionnerait.

Les paquets binaires FreeBSD des ports ne seront pas construits avec une libc différente de la cible - ceci constitue la base du fonctionnement de tous nos tests de configuration.

Une fois validée, cela remplacera inutilement la fonction fournie par le système sous Linux et OS X, @ krader1961.

Fish est construit et lié dynamiquement à une libc partagée sur FreeBSD:

$ ldd fish
fish:
        libncurses.so.8 => /lib/libncurses.so.8 (0x800948000)
        libthr.so.3 => /lib/libthr.so.3 (0x800b9c000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x800dc3000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x801082000)
        libm.so.5 => /lib/libm.so.5 (0x8012a0000)
        libc.so.7 => /lib/libc.so.7 (0x8014cb000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801885000)

Êtes-vous en train de dire avec 100% de certitude que si le comportement du sous-système local change, le numéro de version de libc.so changera? Je n'ai ni le temps ni l'envie d'explorer cette question. Je préfère être prudent étant donné que ma correction n'affectera pas sensiblement le comportement ou les performances des poissons.

Êtes-vous en train de dire avec 100% de certitude que si le comportement du sous-système local change, le numéro de version de libc.so changera?

"pas notre problème".

"pas notre problème"

Bien sûr, c'est notre problème. C'est la raison pour laquelle nous avons fish_wcswidth() et des solutions de contournement similaires aux implémentations cassées.

Le bogue se trouve dans l'outil localedef qui génère les fichiers ctype et provient d'Illumos. Fixé sur DF ici:

https://github.com/DragonFlyBSD/DragonFlyBSD/commit/07ed7d329a83714ec268e2f3ce026bba5a1ac5c2

@jrmarino : Merci pour l'info! Savez-vous quand cela sera intégré aux différents systèmes d'exploitation? Les modifications apportées aux DF parviennent-elles déjà aux utilisateurs?

Corrigé sur FreeBSD également https://svnweb.freebsd.org/base?view=revision&revision=306782

Merci beaucoup bapt! Je viens de passer à FreeBSD 11.0-RELEASE-p1 et bien, c'est vraiment ennuyeux. Savez-vous si ou quand le patch sera intégré à FreeBSD 11.0-RELEASE?

Notez que nous contournons ce bogue dans fish construit à partir de git head. Si vous rencontrez toujours des problèmes avec les poissons de git head sur BSD, faites-le nous savoir. La solution de contournement n'est pas dans fish 2.3.1 ou dans une version antérieure, mais sera dans la prochaine version 2.4.0.

Le changement est plutôt autonome - devrait être facile à rétroporter pour tous les responsables.

Déjà en révision de code.
https://reviews.freebsd.org/D8148

Génial.

@shanavar Je vais fusionner après 1 mois car le changement est plutôt intrusif et je veux m'assurer qu'il n'y a pas d'effets secondaires, une fois cela validé, je demanderai un errata pour 11.0-RELEASE, ce qui signifie que vous pouvez vous y attendre dans environ un mois +

Compiler Fish depuis git fonctionne pour moi sur FreeBSD 11.0-RELEASE-p1:

sudo pkg remove fish
sudo pkg install autoconf  gmake
git clone [email protected]:fish-shell/fish-shell.git
cd fish-shell
autoconf
./configure
gmake
sudo gmake install

Ajoutez ensuite /usr/local/bin/fish à /etc/shells et exécutez chsh -s fish pour changer votre coquille en poisson.

Je n'étais donc pas le seul à avoir ces problèmes. Merci à tous d'avoir corrigé, cela me rendait fou.