Qual tecla você está pressionando? Backspace?

Se isso for verdade, execute bind -k backspace para descobrir como está definido e, em seguida, execute, por exemplo, script (ou bash e pressione ctrl + v) e pressione a tecla para descobrir em qual seqüência ele envia. (Por padrão, o script colocará toda a saída dessa sessão em um arquivo chamado "typescript" no diretório atual). O Xterm deve enviar "\ cH", que peixes devem (via terminfo, que _precisa_ $ TERM para ser definido corretamente) pegar como backspace.

As versões futuras do fish tornarão isso um pouco mais fácil com um pequeno programa auxiliar chamado "fish_key_reader".

Qual é o seu $ TERM definido? "xterm"?

a chave é Backspace.
envie-me um maill e eu darei acesso à minha caixa, deixarei que você descubra o motivo.

a chave é Backspace.

O rótulo da chave não nos diz que sequência de caracteres ela envia. Você pode instalar peixes do código-fonte retirado do repositório git? Se você puder make fish_key_reader seguido de ./fish_key_reader , pressione a tecla Backspace. Se você não puder executar xxd ou od -tx1z , pressione a tecla Backspace seguida de [ctrl-D]. Execute também bind -k backspace e mostre-nos essa saída. Também execute echo $TERM .

Preferiríamos não fazer login em seu sistema por motivos de responsabilidade e porque não lemos chinês, então set LANG zh_CN.UTF-8 será difícil para nós trabalharmos.

./fish_key_reader
999999 usec dec: 8 hex: 8 char: \ b (também conhecido como \ cH)
Para sua informação: Sequência de serra para o nome da chave de ligação "backspace"

bind -k backspace
bind: Nenhuma ligação encontrada para a chave 'backspace'

echo $ TERM
xterm

bind: Nenhuma ligação encontrada para a chave 'backspace'

Ok, esse é o seu problema. Deve dizer algo como

bind -k backspace backward-delete-char

Não vejo como isso pode ter algo a ver com a configuração da variável LANG. De alguma forma, você substituiu as combinações de teclas padrão. Gostaria de pesquisar seus arquivos _ ~ / .config / fish / _ ** por menções da palavra "vincular". Além disso, você está usando algum gerenciador de plug-ins (por exemplo, pescador ou oh-meu-peixe) ou instalou algum outro script de terceiros que possa ser relevante para este problema?

ESTÁ BEM.
o ~ / .config / fish / tem apenas 3 arquivos: 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

sob fish-2.2.0
o 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'

mas sob fish-2.3.0, o comando vincula a saída:

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

Como você instalou o fish 2.3.0? Parece que você está executando um binário fish que não consegue encontrar seus scripts de espaço do usuário.

da fonte

git clone
autoconf
configure
gmake
gmake install

Ok, isso parece razoável. O que os seguintes comandos geram:

echo $__fish_active_key_bindings
echo $fish_function_path

Existe um _fish_default_key_bindings.fish_ em um dos diretórios de caminho de função (geralmente o último listado)? Estou curioso para saber o que functions fish_default_key_bindings produz. Não copie e cole essa saída, mas ela deve corresponder ao que está no arquivo _fish_default_key_bindings.fish_. Além disso, os atalhos de teclado são normalmente configurados pelo script ___ fish_config_interactive.fish_ que deve estar em um dos diretórios listados pelo caminho da função var.

quando excluo .config / fish / config.fish, tudo funciona bem.
mas quando coloco a string set LANG zh_CN.UTF-8 em .config / fish / config.fish ou /usr/local/etc/fish/config.fish, surge o problema.

echo $__fish_active_key_bindings não produz nada.

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

quando excluo .config / fish / config.fish ou comento todas as linhas em /usr/local/etc/fish/config.fish, as saídas são:

echo $__fish_active_key_bindings output:
fish_default_key_bindings

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

o arquivo fish_default_key_bindings.fish está em /usr/local/share/fish/functions/fish_default_key_bindings.fish

Parece que o peixe nunca define os atalhos de teclado.

Isso ocorre porque __fish_config_interactive (que inclui a configuração de vinculação) nunca é executado (o que deve ser feito logo antes de seu primeiro prompt) ou porque seu $ fish_key_bindings está vazio (provavelmente devemos reverter para vínculos padrão se o valor for inválido).

Como parece ser acionado pela configuração de $ LANG, isso aponta para um problema de codificação.

Todos os seus arquivos de configuração e o arquivo fishd podem ser bons em uma forma original, já que não tenho certeza se o github tenta consertar a codificação de forma útil. Além disso, qual é o seu valor de $ LANG se você não defini-lo em config.fish? (Deve ser compatível com ASCII, caso contrário, acho que não poderíamos nem mesmo ler nossos próprios arquivos, mas nunca se sabe)

Eu adicionei set LANG zh_CN.UTF-8 ao meu _config.fish_ e não tive problemas. Como @faho diz, isso parece um problema de codificação de caracteres. Especificamente, seus arquivos de peixes não são codificados como UTF-8. O que file /usr/local/share/fish/functions/__fish_config_interactive.fish reporta? Se disser "texto ASCII", adicione sua linha LANG e inicie um novo shell como este para coletar a saída de depuração:

script
fish -d5
exit
exit

Em seguida, anexe o arquivo _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 diabos? Você está dizendo que fish -d5 não produziu outra saída além de um prompt de shell? Você deve ter obtido uma tonelada de resultados parecidos com o seguinte:

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

O DragonFly é uma referência a https://www.dragonflybsd.org/? Eu me pergunto se este texto naquela página da web, "um novo sistema de localidade", é relevante. Você construiu peixes do git head nesse sistema? Se não, de onde veio o binário do peixe? O que acontece se você em vez disso set LANG C ou set LANG en_US.UTF-8 .

sim, https://www.dragonflybsd.org/ é a página inicial do projeto.
Eu construo a partir da fonte git como:

git clone
autoconf
configure
gmake
gmake install

apenas definir LANG C pode gerar fish -d5 working.outputs 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 é o mesmo resultado que set LANG zh_CN.UTF-8 , não produziu nenhuma saída além de um prompt de shell.

em outra caixa 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 bem.

Ok, há claramente uma incompatibilidade entre fish e as funções char do DragonFly ou um bug no último. Você tem acesso a um sistema DragonFly 4.3 no qual pode construir e testar peixes? Seria bom se pudéssemos começar confirmando que são as mudanças introduzidas no suporte local do DragonFly 4.4 que são as mudanças principais.

Eu testo o último peixe em uma caixa 4.2-RELEASE DragonFly, tudo funciona bem.

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

Ok, por favor fale com os mantenedores do DragonFly. Não estou dizendo que a falha esteja no código deles. Mas é mais provável que tenham uma explicação de por que funções como mbrtowc() e wcrtomb() não estão produzindo o resultado esperado quando fish as chama. É muito improvável que esse comportamento esteja afetando apenas peixes.

Também posso reproduzir isso no DragonFly BSD 4.5-DEVELOPMENT, com qualquer locale UTF-8 (por exemplo, en_AU.UTF-8 ).

@ krader1961
então, você poderia me dar um caso de teste para testar as funções mbrtowc () e wcrtomb ()?

Ok, por favor fale com os mantenedores do DragonFly. Não estou dizendo que a falha esteja no código deles. Mas é mais provável que tenham uma explicação de por que funções como mbrtowc () e wcrtomb () não estão produzindo o resultado esperado quando fish as chama. É muito improvável que esse comportamento esteja afetando apenas peixes.

então, você poderia me dar um caso de teste para testar as funções mbrtowc () e wcrtomb ()?

Eu ia sugerir

$ gmake fish_tests
$ ./fish_tests convert

Mas isso não falha. A execução de todos os testes por meio de ./fish_tests falha em vários testes, mas nada que explique esse problema.

Eu instalei o DragonFly 4.4.3 e construí e instalei o fish a partir do git head. Começar fish com set -x LANG en_US.UTF-8 em meu _config.fish_ produziu muitos erros inesperados, como

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

Não surpreendentemente, bind mostrou muito poucos atalhos de teclado, pois os atalhos padrão são mínimos. O comando locale relatou C até que eu o defina explicitamente en_US.UTF-8 . O primeiro funciona, enquanto o último não. O fato de a localidade padrão do sistema ser "C" em vez de "en_US.UTF-8" é surpreendente. Isso indica que os desenvolvedores do DragonFly reconhecem que seu suporte UTF-8 tem problemas?

Posso ou não passar mais tempo depurando isso. Eu encorajo você a falar com os mantenedores do DragonFly, já que eles provavelmente serão capazes de fornecer informações sobre este problema.

Eu tenho um caso de teste mínimo com fwprintf , então vou perguntar aos tipos de BSD do DragonFly.

Eu ficaria feliz em testar qualquer patch.

Na lista de e-mails do DragonFly BSD, Romick diz :

Eu olhei para o analisador em casca de peixe, você usa caracteres especiais diretamente no fluxo de entrada para marcar coisas diferentes, como BRACKET_BEGIN, BRACKET_END, BRACKET_SEP, INTERNAL_SEPARATOR e assim por diante.

Isso é bom até que você encontre a localidade em que os caracteres são membros completos do alfabeto.
Veja, o intervalo Unicode é de 0x0 a 0x10FFFF e o caractere INTERNAL_SEPARATOR tem um código de 0xFDD7.

No DragonFly BSD, a função iswalnum () verifica todos os locais simultaneamente, então
que você tem três opções:
1) use seu próprio 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 maiores para seus caracteres especiais (não testei isso).

3) outra coisa :)

Estou me perguntando se esse indivíduo sabe alguma coisa sobre Unicode. Esses "caracteres especiais" são caracteres de área de uso privado que são definidos para não serem alfanum: https://en.wikipedia.org/wiki/Unicode_character_property#General_Category. Testei isso no OS X, Linux e DragonFly. E, com certeza, todos os três retornam falso para iswalnum(INTERNAL_SEPARATOR) . Além disso, nunca passamos esses caracteres especiais para funções como fwprintf (), então não vejo por que isso é relevante.

Caso de teste reduzido muito bom @zanchey!

Como você está instalando o DragonflyBSD? Tentei com um ISO noturno e também com o ISO 4.4.3 (usando o Virtualbox) e não consegui reproduzir o problema com o caso de teste reduzido do fwprintf.

editar: Eu também fui capaz de construir e instalar fish no 4.4.3, e os testes também passam, exceto para os testes do notificador.

O caso de teste apenas faz failover de SSH - funciona no console do sistema no VirtualBox.

Oh uau. Você está usando o Vagrant?

Não, simplesmente VirtualBox 5.0.20.

Vou assumir a propriedade disso após fechar o número 3406 como uma duplicata. Tentarei encontrar tempo para instalar o FreeBSD e reproduzir o problema e, se for bem-sucedido, depurá-lo ainda mais.

@lhmwzy, este é provavelmente o mesmo problema que # 3406. Para sua informação, dividi este último problema ao meio e o rastreei para comprometer f2246dfb343bea19beb176fb2cc534f85513b2eb.

Da minha atualização para a edição # 3406 (observe que agora estou trabalhando com FreeBSD 12 em vez de DragonFly BSD):

Para sua informação, instalei o FreeBSD 12 e posso reproduzir esse problema. O motivo pelo qual nenhuma das chaves funciona é que as combinações de teclas padrão não estão configuradas em uma localidade 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'

Existem também outros erros, como alias: Name cannot be empty . Também confirmei que a construção de git checkout f2246df~ não apresenta o problema. O que é muito surpreendente para mim, como autor dessa mudança.

Bom trabalho em encontrar o commit onde o comportamento divergiu. Não está claro para mim o que há de errado com isso.

Existem também outros erros, como alias: o nome não pode estar vazio

@ krader1961 : Este parece ser o mesmo problema que @floam viu: aspas apenas com variáveis ​​nelas resolvem para um argumento vazio - esse erro é emitido quando o alias falha test -z "$name" .

@faho , Sim, eu estava apenas depurando aquela falha da função de alias e cheguei à mesma conclusão. Quer isso seja responsável por todos esses sintomas de BSD ou não, parece um bom lugar para se aprofundar, já que strings entre aspas duplas envolvem um de nossos tokens internos, VARIABLE_EXPAND_SINGLE, que está no intervalo de caracteres reservados unicode.

Além disso, adicionei instruções de depuração e todas as funções isw...() que usamos (por exemplo, iswalnum() ) retornam o resultado correto para esses tokens internos no FreeBSD 12. Portanto, a sugestão dada a @zanchey por alguém em uma lista de discussão do BSD para definir nosso próprio iswalnum é inútil.

Na verdade, você pode reproduzir a expansão var dentro do problema de string entre aspas com bastante facilidade com uma localidade UTF-8 no 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 a pena cavar mais fundo no que está acontecendo ao encerrar uma referência var com aspas duplas. Todos os exemplos acima funcionam bem com LC_ALL = C.

Eu estava errado quando disse algumas horas atrás que iswalnum() retornou a resposta correta no FreeBSD. Por engano, chamei essa função em minha saída de depuração antes de setlocale("") ter sido chamado. Mover essas impressões de depuração mostra que o bloco de 32 pontos de código começando em 0xFDD0 faz com que iswalnum() e iswgraph() retornem um ao invés do valor correto, zero, no FreeBSD, mas não no GNU. Por outro lado GNU incorretamente retorna um para iswgraph() para os caracteres de uso privado começando em 0xF600 que usamos enquanto o FreeBSD retorna corretamente zero.

Portanto, parece que teremos que implementar nossos próprios invólucros em torno dessas funções para obter o comportamento correto, independentemente da plataforma. Preciso pensar um pouco sobre como fazer isso com o mínimo de código adicional e camadas confusas de abstração.

Abri este bug do FreeBSD . Ainda precisaremos solucionar essa implementação interrompida.

Já estabelecemos o padrão de que o código de peixe deve chamar fish_wcswidth() vez de wcswidth() . Nós consagramos isso como uma regra cppcheck (consulte _.cppcheck.rule_). Poderíamos fazer a mesma coisa para a família de funções isw...() . Mas essa é a melhor solução? Certamente é o mais fácil de implementar. Alguém tem uma solução melhor?

PS, estou inclinado a classificar esse problema como um "aprimoramento" em vez de um "bug", porque estamos falando sobre aprimorar peixes para contornar um bug em uma das plataformas que suportamos. Sim? Não? Quem se importa? :sorriso:

PPS, eu verifiquei que substituir a plataforma fornecida iswalnum() corrige esse problema no FreeBSD 12.

Minha maneira preferida de lidar com isso seria verificar o comportamento no momento da configuração e substituir as funções se e somente se elas forem incompatíveis a esse respeito.

Não vou basear a substituição das funções da plataforma em testes de autoconf. Primeiro, vimos instâncias de distros que apresentam comportamento correto (ou incorreto) em uma versão e, em seguida, invertem o comportamento em uma versão subsequente. Um binário construído para o FreeBSD 10, por exemplo, ainda deve funcionar corretamente no FreeBSD 12. Basear nosso comportamento em um teste autoconf não resolve isso. Em segundo lugar, os testes em questão são extremamente baratos, mesmo se os agruparmos para garantir o comportamento correto e as chamadas para as funções afetadas não estão em loops de desempenho críticos. Terceiro, precisamos de uma das funções auxiliares que esta mudança apresentará para garantir que não permitamos que os usuários injetem nossos pontos de código de uso interno mágico (que está na minha lista TODO) em nosso estado interno.

Além disso, para registro, quando escrevi a seguinte declaração em um comentário anterior, inverti as duas distros:

Por outro lado GNU incorretamente retorna um para iswgraph () para os caracteres de uso privado começando em 0xF600 que usamos enquanto o FreeBSD retorna corretamente zero.

De acordo com o código do FAQ Unicode, os pontos nas áreas de uso privado devem ser classificados como tendo um glifo associado (ou seja, iswgraph() deve retornar um), mas não são alfanuméricos (ou seja, iswalnum() deve retornar zero).

Para mim, um teste de autoconf verificando o resultado de iswalnum () em um desses valores funcionaria.

Os pacotes binários do FreeBSD dos ports não serão construídos contra uma libc diferente do destino - isto forma a base de como todos os nossos testes de tempo de configuração funcionam.

Conforme confirmado, isso substituirá desnecessariamente a função fornecida pelo sistema no Linux e no OS X, @ krader1961.

O Fish é construído e vinculado dinamicamente a uma libc compartilhada no 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)

Você está dizendo com 100% de certeza que se o comportamento do subsistema local mudar, o número da versão libc.so mudará? Não tenho tempo nem inclinação para explorar essa questão. Prefiro ser conservador, pois minha correção não afetará de forma perceptível o comportamento ou o desempenho dos peixes.

Você está dizendo com 100% de certeza que se o comportamento do subsistema local mudar, o número da versão libc.so mudará?

"não é nosso problema".

"não é nosso problema"

Claro que é nosso problema. É a razão pela qual temos fish_wcswidth() e soluções alternativas para implementações quebradas.

O bug está na ferramenta localedef que gera os arquivos ctype e se originou com Illumos. Fixo no DF aqui:

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

@jrmarino : Obrigado pela informação! Você sabe quando isso vai chegar aos vários sistemas operacionais? A mudança de DFs já está chegando aos usuários?

Também corrigido no FreeBSD https://svnweb.freebsd.org/base?view=revision&revision=306782

Muito obrigado batizado! Acabei de atualizar para o FreeBSD 11.0-RELEASE-p1 e bem, isso é seriamente irritante. Você sabe se ou quando o patch será integrado ao FreeBSD 11.0-RELEASE?

Observe que contornamos esse bug em peixes criados a partir do git head. Se você ainda estiver tendo problemas com o fish from git head no BSD, avise-nos. A solução alternativa não está no fish 2.3.1 ou em qualquer versão anterior, mas estará na próxima versão 2.4.0.

A mudança é bastante independente - deve ser fácil de transportar para qualquer mantenedor por aí.

Já em revisão de código.
https://reviews.freebsd.org/D8148

Ótimo.

@shanavar eu irei fundir após 1 mês porque a mudança é bastante intrusiva e eu quero ter certeza de que não há efeitos colaterais, uma vez que isso seja validado eu vou solicitar uma errata para 11.0-RELEASE, o que significa que você pode esperar por cerca de um mês +

Compilar Fish do git funciona para mim no 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

Em seguida, adicione /usr/local/bin/fish a /etc/shells e execute chsh -s fish para mudar sua concha para Peixe.

Então, eu não era o único com esses problemas. Obrigado a todos por corrigirem, isso estava me deixando louco.