¿Qué tecla estás presionando? Retroceso?

Si eso es cierto, ejecute bind -k backspace para averiguar en qué está configurado, y luego ejecute, por ejemplo, script (o bash y presione ctrl + v) y presione la tecla para averiguar qué secuencia envía. (El script pondrá por defecto toda la salida de esa sesión en un archivo llamado "mecanografiado" en el directorio actual). Xterm debería enviar "\ cH", que fish debería (a través de terminfo, que _needs_ $ TERM debe configurarse correctamente) seleccionar como retroceso.

Las futuras versiones de Fish harán esto algo más fácil con un pequeño programa auxiliar llamado "fish_key_reader".

¿En qué está configurado su $ TERM? "xterm"?

la clave es Retroceso.
por favor envíeme un correo, y le daré acceso a mi buzón, le dejaré averiguar el motivo.

la clave es Retroceso.

La etiqueta de la tecla no nos dice qué secuencia de caracteres envía. ¿Puedes instalar pescado de la fuente extraída del repositorio de git? Si puede, entonces make fish_key_reader seguido de ./fish_key_reader entonces presione la tecla de retroceso. Si no puede ejecutar xxd o od -tx1z luego presione la tecla de retroceso seguida de [ctrl-D]. También ejecute bind -k backspace y muéstrenos ese resultado. También ejecute echo $TERM .

Preferiríamos no iniciar sesión en su sistema tanto por motivos de responsabilidad como porque no leemos chino, por lo que será difícil para nosotros trabajar con set LANG zh_CN.UTF-8 .

./fish_key_reader
999999 usec dec: 8 hex: 8 char: \ b (también conocido como \ cH)
FYI: Secuencia de sierra para vincular el nombre de la tecla "retroceso"

enlazar -k retroceso
enlazar: No se encontró enlace para la clave 'retroceso'

echo $ TERM
xterm

enlazar: No se encontró enlace para la clave 'retroceso'

De acuerdo, ese es tu problema. Debería decir algo como

bind -k backspace backward-delete-char

No veo cómo esto podría tener algo que ver con la configuración de la variable LANG. De alguna manera ha anulado las combinaciones de teclas predeterminadas. Buscaría en sus archivos _ ~ / .config / fish / _ ** menciones de la palabra "bind". Además, ¿está utilizando administradores de complementos (por ejemplo, fisherman o oh-my-fish) o ha instalado algún otro script de terceros que pueda ser relevante para este problema?

OKAY.
el ~ / .config / fish / solo tiene 3 archivos: 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

bajo fish-2.2.0
el comando 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'

pero bajo fish-2.3.0, el comando bind output:

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

¿Cómo instalaste Fish 2.3.0? Parece que está ejecutando un binario fish que no puede encontrar sus scripts de espacio de usuario.

de la fuente

git clone
autoconf
configure
gmake
gmake install

Está bien, eso parece razonable. ¿Qué dan salida a los siguientes comandos?

echo $__fish_active_key_bindings
echo $fish_function_path

¿Hay un _fish_default_key_bindings.fish_ en uno de los directorios de ruta de función (normalmente el último en la lista)? Tengo curiosidad por saber qué salidas functions fish_default_key_bindings . No copie y pegue esa salida, pero debería coincidir con lo que está en el archivo _fish_default_key_bindings.fish_. Además, los enlaces de teclas normalmente se configuran mediante el script ___ fish_config_interactive.fish_ que debería estar en uno de los directorios enumerados por la ruta de la función var.

cuando elimino .config / fish / config.fish, todo funciona bien.
pero cuando pongo la cadena set LANG zh_CN.UTF-8 en .config / fish / config.fish o /usr/local/etc/fish/config.fish, surge el problema.

echo $__fish_active_key_bindings no genera nada.

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

cuando elimino .config / fish / config.fish o comento todas las líneas en /usr/local/etc/fish/config.fish, los resultados son:

echo $__fish_active_key_bindings salida:
fish_default_key_bindings

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

el archivo fish_default_key_bindings.fish está en /usr/local/share/fish/functions/fish_default_key_bindings.fish

Parece que Fish nunca establece las combinaciones de teclas.

Esto se debe a que __fish_config_interactive (que incluye la configuración de enlace) nunca se ejecuta (que debería ser justo antes de su primer mensaje) o porque su $ fish_key_bindings está vacío (probablemente deberíamos volver a los enlaces predeterminados si el valor es no es válido).

Como parece que se activa al configurar $ LANG, apunta a un problema de codificación.

Todos sus archivos de configuración y el archivo fishd pueden estar bien en una forma prístina, ya que no estoy seguro de si github intenta arreglar la codificación de manera útil. Además, ¿cuál es su valor de $ LANG si no lo establece en config.fish? (Debería ser compatible con ASCII, ya que de lo contrario no creo que podamos leer nuestros propios archivos, pero nunca se sabe)

Agregué set LANG zh_CN.UTF-8 a mi _config.fish_ y no tuve problemas. Como dice @faho , esto parece un problema de codificación de caracteres. Específicamente, sus archivos fish no están codificados como UTF-8. ¿Qué informa file /usr/local/share/fish/functions/__fish_config_interactive.fish ? Si dice "texto ASCII", agregue su línea LANG y luego inicie un nuevo shell como este para recopilar la salida de depuración:

script
fish -d5
exit
exit

Luego adjunte el archivo _typescript_ a este problema.

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 demonios? ¿Está diciendo que fish -d5 no produjo más salida que un indicador de shell? Debería haber obtenido una gran cantidad de resultados que se parecen a lo siguiente:

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

¿DragonFly es una referencia a https://www.dragonflybsd.org/? Me pregunto si este texto en esa página web, "un nuevo sistema local", es relevante. ¿Construiste peces de git head en ese sistema? Si no es así, ¿de dónde vino el binario de peces? ¿Qué sucede si, en cambio, set LANG C o set LANG en_US.UTF-8 ?

sí, https://www.dragonflybsd.org/ es la página de inicio del proyecto.
Construyo desde una fuente de git como:

git clone
autoconf
configure
gmake
gmake install

solo establecer LANG C puede hacer que fish -d5 funcionen salidas como:

<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 es el mismo resultado que set LANG zh_CN.UTF-8 , no produjo más salida que un indicador de shell.

en otra caja 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 funciona bien.

De acuerdo, existe claramente una incompatibilidad entre fish y las funciones de caracteres amplios de DragonFly o un error en esta última. ¿Tiene acceso a un sistema DragonFly 4.3 en el que puede construir y probar peces? Sería bueno si pudiéramos comenzar confirmando que los cambios introducidos en el soporte de configuración regional de DragonFly 4.4 son el cambio clave.

Probé el último pez en una caja DragonFly de versión 4.2, todo funciona 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

Bien, hable con los mantenedores de DragonFly. No digo que la culpa sea de su código. Pero es más probable que tengan una explicación de por qué funciones como mbrtowc() y wcrtomb() no producen el resultado esperado cuando fish las llama. Es muy poco probable que este comportamiento solo afecte a los peces.

También puedo reproducir esto en DragonFly BSD 4.5-DEVELOPMENT, con cualquier configuración regional UTF-8 (por ejemplo, en_AU.UTF-8 ).

@ krader1961
Entonces, ¿podría darme un caso de prueba para probar las funciones mbrtowc () y wcrtomb ()?

Bien, hable con los mantenedores de DragonFly. No digo que la culpa sea de su código. Pero es más probable que tengan una explicación de por qué funciones como mbrtowc () y wcrtomb () no producen el resultado esperado cuando fish las llama. Es muy poco probable que este comportamiento solo afecte a los peces.

Entonces, ¿podría darme un caso de prueba para probar las funciones mbrtowc () y wcrtomb ()?

Iba a sugerir

$ gmake fish_tests
$ ./fish_tests convert

Pero eso no falla. La ejecución de todas las pruebas a través de ./fish_tests falla en varias pruebas, pero nada que explique este problema.

Instalé DragonFly 4.4.3 y construí e instalé fish desde git head. Empezar a pescar con set -x LANG en_US.UTF-8 en mi _config.fish_ produjo muchos errores inesperados como

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

No es sorprendente que bind mostrara muy pocas combinaciones de teclas, ya que las combinaciones predeterminadas son mínimas. El comando locale informó C hasta que lo configuré explícitamente en en_US.UTF-8 . El primero funciona mientras que el segundo no. El hecho de que la configuración regional predeterminada del sistema sea "C" en lugar de "en_US.UTF-8" es sorprendente. ¿Eso indica que los desarrolladores de DragonFly reconocen que su compatibilidad con UTF-8 tiene problemas?

Puedo o no dedicar más tiempo a depurar esto. Le animo a que hable con los mantenedores de DragonFly, ya que es probable que puedan proporcionar información sobre este problema.

Tengo un caso de prueba bastante mínimo con fwprintf , así que preguntaré a los tipos de DragonFly BSD.

Me encantaría probar cualquier parche.

En la lista de correo de DragonFly BSD, Romick dice :

Miré el analizador en forma de concha de pescado, usas caracteres especiales directamente en el flujo de entrada para marcar diferentes cosas, como BRACKET_BEGIN, BRACKET_END, BRACKET_SEP, INTERNAL_SEPARATOR y así sucesivamente.

Esto está bien hasta que haya encontrado la configuración regional en la que los caracteres son miembros completos del alfabeto.
Verá, el rango Unicode es de 0x0 a 0x10FFFF, y el carácter INTERNAL_SEPARATOR tiene un código de 0xFDD7.

En la función DragonFly BSD, iswalnum () comprueba todas las configuraciones regionales simultáneamente, por lo que
que tienes tres opciones:
1) use su propio 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) use valores más grandes para sus caracteres especiales (no he probado esto).

3) algo más :)

Me pregunto si ese individuo sabe algo sobre Unicode. Esos "caracteres especiales" son caracteres de área de uso privado que se definen como no alfanumos: https://en.wikipedia.org/wiki/Unicode_character_property#General_Category. Probé esto en OS X, Linux y DragonFly. Y, efectivamente, los tres devuelven falso por iswalnum(INTERNAL_SEPARATOR) . Además, nunca pasamos esos caracteres especiales a funciones como fwprintf (), así que no veo por qué esto es incluso relevante.

¡Un caso de prueba reducido realmente agradable @zanchey!

¿Cómo está instalando DragonflyBSD? Probé con un ISO nocturno y también con el ISO de la versión 4.4.3 (usando Virtualbox) y no pude reproducir el problema con el caso de prueba reducido de fwprintf.

editar: También pude construir e instalar fish en 4.4.3, y las pruebas también pasan, excepto las pruebas del notificador.

El caso de prueba solo falla en SSH: funciona en la consola del sistema en VirtualBox.

Oh wow. ¿Estás usando Vagrant?

No, simplemente VirtualBox 5.0.20.

Voy a tomar posesión de esto después de cerrar # 3406 como duplicado. Intentaré encontrar el tiempo para instalar FreeBSD y reproducir el problema y, si tiene éxito, lo depuraré más.

@lhmwzy este es probablemente el mismo problema que el # 3406. Para su información, dividí en dos este último problema y lo rastreé para confirmar f2246dfb343bea19beb176fb2cc534f85513b2eb.

De mi actualización al número 3406 (tenga en cuenta que ahora estoy trabajando con FreeBSD 12 en lugar de DragonFly BSD):

FYI, instalé FreeBSD 12 y puedo reproducir este problema. La razón por la que ninguna de las claves funciona es que las combinaciones de teclas predeterminadas no están configuradas en una configuración regional 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'

También hay otros errores como alias: Name cannot be empty . También confirmé que construir desde git checkout f2246df~ no presenta el problema. Lo cual es muy sorprendente para mí como autor de ese cambio.

Buen trabajo al encontrar el compromiso donde el comportamiento divergió. Sin embargo, no tengo claro qué estaría mal con eso.

También hay otros errores, como alias: el nombre no puede estar vacío

@ krader1961 : Este parece ser el mismo problema @floam saw: las citas con solo variables en ellas se resuelven en un argumento vacío; ese error se emite cuando el alias falla test -z "$name" .

@faho , Sí, solo estaba depurando la falla de la función de alias y llegué a la misma conclusión. Ya sea que eso explique todos estos síntomas de BSD o no, parece un buen lugar para profundizar, ya que las cadenas entre comillas dobles involucran uno de nuestros tokens internos, VARIABLE_EXPAND_SINGLE, que está en el rango de caracteres reservados de Unicode.

Además, agregué declaraciones de depuración y todas las funciones isw...() que usamos (por ejemplo, iswalnum() ) devuelven el resultado correcto para esos tokens internos en FreeBSD 12. Entonces, la sugerencia que alguien le dio a @zanchey en una lista de correo BSD para definir nuestro propio iswalnum es inútil.

De hecho, puede reproducir la expansión var dentro del problema de cadenas entre comillas dobles con bastante facilidad con una configuración regional UTF-8 en 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

Definitivamente vale la pena profundizar en lo que sucede al terminar una referencia var con una comilla doble. Todos los ejemplos anteriores funcionan bien con LC_ALL = C.

Me equivoqué cuando dije hace unas horas que iswalnum() devolvió la respuesta correcta en FreeBSD. Llamé erróneamente a esa función en mi salida de depuración antes de que se llamara setlocale("") . Mover esas impresiones de depuración muestra que el bloque de 32 puntos de código que comienza en 0xFDD0 hace que iswalnum() y iswgraph() devuelvan uno en lugar del valor correcto, cero, en FreeBSD pero no en GNU. Por otro lado GNU devuelve incorrectamente uno por iswgraph() para los caracteres de uso privado que comienzan en 0xF600 que usamos mientras FreeBSD devuelve correctamente cero.

Entonces, parece que vamos a tener que implementar nuestros propios contenedores alrededor de esas funciones para obtener el comportamiento correcto independientemente de la plataforma. Necesito pensar un poco sobre cómo hacer eso con la mínima cantidad de código adicional y capas confusas de abstracción.

Abrí este error de FreeBSD . Todavía necesitaremos solucionar esta implementación rota.

Ya hemos establecido el patrón que el código de pescado debe llamar fish_wcswidth() lugar de wcswidth() . Lo hemos consagrado como una regla cppcheck (ver _.cppcheck.rule_). Podríamos hacer lo mismo para la familia de funciones isw...() . ¿Pero es esa la mejor solución? Sin duda, es el más fácil de implementar. ¿Alguien tiene una solución mejor?

PD: Me inclino a clasificar este problema como una "mejora" en lugar de un "error" porque estamos hablando de mejorar el pescado para solucionar un error en una de las plataformas que admitimos. ¿Si? ¿No? ¿A quien le importa? :sonreír:

PPS, he verificado que anular la plataforma proporcionada iswalnum() soluciona este problema en FreeBSD 12.

Mi forma preferida de manejar esto sería verificar el comportamiento en el momento de la configuración y anular las funciones si y solo si son incompatibles en este sentido.

No voy a basar la anulación de las funciones de la plataforma en pruebas de autoconf. Primero, hemos visto instancias de distribuciones que tienen un comportamiento correcto (o incorrecto) en una versión y luego cambiamos el comportamiento en una versión posterior. Un binario construido para FreeBSD 10, por ejemplo, debería funcionar correctamente en FreeBSD 12. Basar nuestro comportamiento en una prueba de autoconf no maneja eso. En segundo lugar, las pruebas en cuestión son extremadamente baratas incluso si las ajustamos para garantizar un comportamiento correcto y las llamadas a las funciones afectadas no se encuentran en bucles de rendimiento críticos. En tercer lugar, necesitamos una de las funciones auxiliares que introducirá este cambio para garantizar que no permitamos a los usuarios inyectar nuestros puntos de código de uso interno mágico (que están en mi lista TODO) en nuestro estado interno.

Además, para que conste, cuando escribí la siguiente declaración en un comentario anterior, tenía las dos distribuciones invertidas:

Por otro lado GNU devuelve incorrectamente uno para iswgraph () para los caracteres de uso privado que comienzan en 0xF600 que usamos mientras FreeBSD devuelve correctamente cero.

De acuerdo con las preguntas frecuentes de Unicode, los puntos de código en las áreas de uso privado están destinados a clasificarse con un glifo asociado (es decir, iswgraph() deben devolver uno) pero no son alfanuméricos (es decir, iswalnum() deben devolver cero).

Me parece que una prueba de autoconf que verifica el resultado de iswalnum () en uno de estos valores funcionaría.

Los paquetes binarios de FreeBSD de los puertos no se construirán contra una libc diferente a la de destino; esto forma la base de cómo funcionan todas nuestras pruebas de tiempo de configuración.

Como se comprometió, esto anulará la función proporcionada por el sistema innecesariamente en Linux y OS X también, @ krader1961.

Fish está construido y vinculado dinámicamente con una libc compartida en 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)

¿Está diciendo con 100% de certeza que si el comportamiento del subsistema de configuración regional cambia, el número de versión de libc.so cambiará? No tengo tiempo ni ganas de explorar esa cuestión. Preferiría ser conservador dado que mi solución no afectará notablemente el comportamiento o el rendimiento de los peces.

¿Está diciendo con 100% de certeza que si el comportamiento del subsistema de configuración regional cambia, el número de versión de libc.so cambiará?

"no es nuestro problema".

"no es nuestro problema"

Por supuesto que es nuestro problema. Es la razón por la que tenemos fish_wcswidth() y soluciones alternativas similares para implementaciones fallidas.

El error está en la herramienta localedef que genera los archivos ctype y se originó con Illumos. Corregido en DF aquí:

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

@jrmarino : ¡Gracias por la información! ¿Sabes cuándo llegará a los distintos sistemas operativos? ¿Los cambios de DF ya están llegando a los usuarios?

También se corrigió en FreeBSD

¡Muchas gracias bapt! Acabo de actualizar a FreeBSD 11.0-RELEASE-p1 y bueno, esto es muy molesto. ¿Sabe si el parche se integrará a FreeBSD 11.0-RELEASE o cuándo se integrará?

Tenga en cuenta que solucionamos este error en peces creados a partir de git head. Si todavía tiene problemas con el pescado de git head en BSD, háganoslo saber. La solución alternativa no está en Fish 2.3.1 ni en ninguna versión anterior, pero estará en la próxima versión 2.4.0.

El cambio es bastante autónomo: debería ser fácil de respaldar para cualquier personal de mantenimiento.

Ya en revisión de código.
https://reviews.freebsd.org/D8148

Excelente.

@shanavar Me fusionaré después de 1 mes porque el cambio es bastante intrusivo y quiero asegurarme de que no haya efectos secundarios, una vez que esto esté validado, solicitaré una errata para 11.0-RELEASE, lo que significa que puede esperarlo en aproximadamente un mes +

Compilar Fish desde git me funciona en 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

Luego agregue /usr/local/bin/fish a /etc/shells y ejecute chsh -s fish para cambiar su caparazón a Fish.

Entonces no fui el único con estos problemas. Gracias a todos por corregir, esto me estaba volviendo loco.