Fish-shell: UTF-8-Gebietsschemas funktionieren nicht mit DragonFly BSD, FreeBSD 11, 12

Erstellt am 21. Mai 2016  ·  60Kommentare  ·  Quelle: fish-shell/fish-shell

wenn Sie eine Zeile wie folgt setzen:
set LANG zh_CN.UTF-8
zu .config / fish / config.fish
kann dann kein Zeichen löschen, wenn der Befehl falsch ist.

zum Beispiel:

cate

Ich möchte 'e' für den Befehl 'cat' löschen.
kann aber kein Zeichen löschen
unter 2.2.0 ist in Ordnung.


Fischversion: Fisch, Version 2.3.0

Betriebssystem: DragonFly testdf.com 4.4-RELEASE DragonFly v4.4.1.18.gc5db8-RELEASE # 0: Do 28 Jan 15:02:10 CST 2016 [email protected] : / usr / obj / usr / src / sys / lhmwzy x86_64

Terminal oder Terminalemulator: xterm

bug

Hilfreichster Kommentar

Ich habe diesen FreeBSD-Fehler geöffnet. Wir müssen diese kaputte Implementierung noch umgehen.

Alle 60 Kommentare

Welche Taste drückst du? Rücktaste?

Wenn dies zutrifft, führen Sie bitte bind -k backspace , um herauszufinden, auf was es eingestellt ist, und führen Sie dann z. B. script (oder Bash und drücken Sie Strg + V) und drücken Sie die Taste, um herauszufinden, welche Sequenz es sendet. (Das Skript speichert standardmäßig die gesamte Ausgabe dieser Sitzung in einer Datei namens "Typoskript" im aktuellen Verzeichnis.) Xterm sollte "\ cH" senden, welcher Fisch (über terminfo, welcher _TerM $ TERM muss richtig eingestellt werden) als Rücktaste aufgenommen werden soll.

Zukünftige Fischversionen werden dies mit einem kleinen Hilfsprogramm namens "fish_key_reader" etwas einfacher machen.

Auf was ist Ihr $ TERM eingestellt? "xterm"?

Der Schlüssel ist die Rücktaste.
Bitte senden Sie mir ein Maill, und ich werde Ihnen meine Box zugänglich machen, damit Sie den Grund herausfinden.

Der Schlüssel ist die Rücktaste.

Das Etikett auf dem Schlüssel sagt uns nicht, welche Zeichenfolge es sendet. Können Sie Fische aus der Quelle installieren, die aus dem Git-Repository gezogen wurden? Wenn Sie dann make fish_key_reader gefolgt von ./fish_key_reader drücken Sie Ihre Rücktaste. Wenn Sie xxd oder od -tx1z nicht ausführen können, drücken Sie die Rücktaste, gefolgt von [Strg-D]. Führen Sie auch bind -k backspace und zeigen Sie uns diese Ausgabe. Führen Sie auch echo $TERM .

Wir möchten uns aus Haftungsgründen und weil wir kein Chinesisch lesen, lieber nicht bei Ihrem System anmelden, sodass es für uns schwierig sein wird, mit set LANG zh_CN.UTF-8 zu arbeiten.

./fish_key_reader
999999 usec dec: 8 hex: 8 char: \ b (auch bekannt als \ cH)
Zu Ihrer Information: Sägefolge für den Bindeschlüsselnamen "Rücktaste"

bind -k Rücktaste
bind: Keine Bindung für Schlüssel 'Rücktaste' gefunden

echo $ TERM
xterm

bind: Keine Bindung für Schlüssel 'Rücktaste' gefunden

Okay, das ist dein Problem. Es sollte so etwas sagen

bind -k backspace backward-delete-char

Ich sehe nicht ein, wie dies etwas mit dem Setzen der LANG-Variablen zu tun haben könnte. Sie haben die Standardschlüsselbindungen irgendwie überschrieben. Ich würde Ihre _ ~ / .config / fish / _ ** -Dateien nach Erwähnungen des Wortes "bind" durchsuchen. Verwenden Sie auch Plugin-Manager (z. B. Fisherman oder Oh-My-Fish) oder haben Sie andere Skripte von Drittanbietern installiert, die für dieses Problem relevant sein könnten?

IN ORDNUNG.
Die ~ / .config / fish / haben nur 3 Dateien: 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

unter Fisch-2.2.0
der Befehl 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'

aber unter fish-2.3.0 gibt der Befehl bind output aus:

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

Wie haben Sie fish 2.3.0 installiert? Es sieht so aus, als würden Sie eine Fish-Binärdatei ausführen, die ihre User-Space-Skripte nicht finden kann.

von der Quelle

git clone
autoconf
configure
gmake
gmake install

Okay, das sieht vernünftig aus. Was geben die folgenden Befehle aus:

echo $__fish_active_key_bindings
echo $fish_function_path

Befindet sich in einem der Funktionspfadverzeichnisse ein _fish_default_key_bindings.fish_ (normalerweise das zuletzt aufgeführte)? Ich bin gespannt, was functions fish_default_key_bindings ausgibt. Kopieren Sie diese Ausgabe nicht, sondern fügen Sie sie in die Datei _fish_default_key_bindings.fish_ ein. Außerdem werden die Tastenkombinationen normalerweise vom Skript ___ fish_config_interactive.fish_ eingerichtet, das sich in einem der Verzeichnisse befinden sollte, die im Funktionspfad var aufgeführt sind.

Wenn ich .config / fish / config.fish lösche, läuft alles gut.
Aber wenn ich die Zeichenfolge set LANG zh_CN.UTF-8 in .config / fish / config.fish oder /usr/local/etc/fish/config.fish setze, tritt das Problem auf.

echo $__fish_active_key_bindings gibt nichts aus.

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

Wenn ich .config / fish / config.fish lösche oder alle Zeilen in /usr/local/etc/fish/config.fish kommentiere, sind die Ausgaben:

echo $__fish_active_key_bindings Ausgabe:
fish_default_key_bindings

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

Die Datei fish_default_key_bindings.fish befindet sich in /usr/local/share/fish/functions/fish_default_key_bindings.fish

Es scheint, dass Fisch niemals die Schlüsselbindungen setzt.

Dies liegt entweder daran, dass __fish_config_interactive (einschließlich des Bindungs-Setups) niemals ausgeführt wird (was direkt vor Ihrer ersten Eingabeaufforderung sein sollte) oder daran, dass Ihre $ fish_key_bindings leer sind (wir sollten wahrscheinlich auf Standardbindungen zurückgreifen, wenn der Wert ist ungültig).

Da es durch das Setzen von $ LANG ausgelöst zu werden scheint, weist es auf ein Codierungsproblem hin.

Alle Ihre Konfigurationsdateien und die fishd-Datei könnten in makelloser Form nett sein, da ich nicht sicher bin, ob github hilfreich versucht, die Codierung zu korrigieren. Was ist Ihr $ LANG-Wert, wenn Sie ihn nicht in config.fish festlegen? (Es sollte ASCII-kompatibel sein, da wir sonst nicht einmal unsere eigenen Dateien lesen könnten, aber Sie wissen es nie)

Ich habe set LANG zh_CN.UTF-8 _ @faho sagt, scheint dies ein Problem mit der Zeichenkodierung zu sein. Insbesondere sind Ihre Fischdateien nicht als UTF-8 codiert. Was meldet file /usr/local/share/fish/functions/__fish_config_interactive.fish ? Wenn "ASCII-Text" angezeigt wird, fügen Sie Ihre LANG-Zeile hinzu und starten Sie eine neue Shell wie diese, um die Debugging-Ausgabe zu erfassen:

script
fish -d5
exit
exit

Hängen Sie dann die Datei _typescript_ an dieses Problem an.

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

Was zum Teufel? Sie sagen, dass fish -d5 keine andere Ausgabe als eine Shell-Eingabeaufforderung erzeugt hat? Sie sollten eine Tonne Ausgabe erhalten haben, die wie folgt aussieht:

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

Ist DragonFly ein Verweis auf https://www.dragonflybsd.org/? Ich frage mich, ob dieser Text auf dieser Webseite, "ein neues Gebietsschemasystem", relevant ist. Haben Sie auf diesem System Fisch aus Git Head gebaut? Wenn nicht, woher kommt die Fisch-Binärdatei? Was passiert, wenn Sie stattdessen set LANG C oder set LANG en_US.UTF-8 .

Ja, https://www.dragonflybsd.org/ ist die Projekthomepage.
Ich baue aus Git-Quellen wie:

git clone
autoconf
configure
gmake
gmake install

Nur LANG C kann fish -d5 funktionieren lassen. Ausgaben wie:

<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 ist das gleiche Ergebnis wie set LANG zh_CN.UTF-8 , es wurde nur eine Shell-Eingabeaufforderung ausgegeben.

auf einer anderen DF 4.4-Box

/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 läuft OK.

Okay, es gibt eindeutig eine Inkompatibilität zwischen Fisch und den DragonFly Wide Char-Funktionen oder einen Fehler in letzterem. Haben Sie Zugriff auf ein DragonFly 4.3-System, auf dem Sie Fische bauen und testen können? Es wäre schön, wenn wir zunächst bestätigen könnten, dass die Änderungen, die an der Unterstützung des DragonFly 4.4-Gebietsschemas vorgenommen wurden, die Schlüsseländerung sind.

Ich teste den neuesten Fisch auf einer 4.2-RELEASE DragonFly-Box, alles läuft in Ordnung.

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

Okay, bitte sprechen Sie mit den DragonFly-Betreuern. Ich sage nicht, dass der Fehler in ihrem Code liegt. Es ist jedoch wahrscheinlicher, dass sie eine Erklärung dafür haben, warum Funktionen wie mbrtowc() und wcrtomb() nicht das erwartete Ergebnis liefern, wenn Fische sie aufrufen. Es ist sehr unwahrscheinlich, dass dieses Verhalten nur Fische betrifft.

Ich kann dies auch auf DragonFly BSD 4.5-DEVELOPMENT mit jedem UTF-8-Gebietsschema (z. B. en_AU.UTF-8 ) reproduzieren.

@ krader1961
Könnten Sie mir bitte einen Testfall zum Testen der Funktionen mbrtowc () und wcrtomb () geben?

Okay, bitte sprechen Sie mit den DragonFly-Betreuern. Ich sage nicht, dass der Fehler in ihrem Code liegt. Es ist jedoch wahrscheinlicher, dass sie eine Erklärung dafür haben, warum Funktionen wie mbrtowc () und wcrtomb () nicht das erwartete Ergebnis liefern, wenn Fische sie aufrufen. Es ist sehr unwahrscheinlich, dass dieses Verhalten nur Fische betrifft.

Könnten Sie mir bitte einen Testfall zum Testen der Funktionen mbrtowc () und wcrtomb () geben?

Ich würde vorschlagen

$ gmake fish_tests
$ ./fish_tests convert

Das scheitert aber nicht. Das Ausführen aller Tests über ./fish_tests schlägt mehrere Tests fehl, aber nichts, was dieses Problem erklären würde.

Ich habe DragonFly 4.4.3 installiert und Fische aus Git Head gebaut und installiert. Das Starten von Fisch mit set -x LANG en_US.UTF-8 in meiner _config.fish_ verursachte viele unerwartete Fehler wie z

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

Es überrascht nicht, dass bind sehr wenige Tastenbindungen aufwies, da die Standardbindungen minimal sind. Der Befehl locale hat C gemeldet, bis ich ihn explizit auf en_US.UTF-8 . Ersteres funktioniert, letzteres nicht. Die Tatsache, dass das Standardgebietsschema des Systems "C" und nicht "en_US.UTF-8" ist, ist überraschend. Zeigt dies an, dass die DragonFly-Entwickler erkennen, dass ihre UTF-8-Unterstützung Probleme hat?

Ich kann oder kann nicht mehr Zeit damit verbringen, dies zu debuggen. Ich empfehle Ihnen, mit den DragonFly-Betreuern zu sprechen, da diese wahrscheinlich einen Einblick in dieses Problem gewähren können.

Ich habe einen ziemlich minimalen Testfall mit fwprintf , also werde ich die DragonFly BSD-Typen fragen.

Ich würde gerne jeden Patch testen.

Auf der DragonFly BSD-Mailingliste sagt Romick :

Ich habe mir den Parser in Fish-Shell angesehen. Sie verwenden Sonderzeichen direkt im Eingabestream, um verschiedene Dinge zu markieren, z. B. BRACKET_BEGIN, BRACKET_END, BRACKET_SEP, INTERNAL_SEPARATOR usw.

Dies ist in Ordnung, bis Sie das Gebietsschema erreicht haben, in dem die Zeichen Vollmitglieder des Alphabets sind.
Sie sehen, der Unicode-Bereich liegt zwischen 0x0 und 0x10FFFF, und das Zeichen INTERNAL_SEPARATOR hat den Code 0xFDD7.

In der DragonFly BSD-Funktion überprüft iswalnum () alle Gebietsschemas gleichzeitig
dass Sie drei Möglichkeiten haben:
1) benutze dein eigenes 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) Verwenden Sie größere Werte für Ihre Sonderzeichen (ich habe dies nicht getestet).

3) etwas anderes :)

Ich frage mich, ob diese Person etwas über Unicode weiß. Diese "Sonderzeichen" sind Zeichen für den privaten Gebrauch, die als keine Alphanums definiert sind: https://en.wikipedia.org/wiki/Unicode_character_property#General_Category. Ich habe dies unter OS X, Linux und DragonFly getestet. Und natürlich geben alle drei für iswalnum(INTERNAL_SEPARATOR) false zurück. Außerdem übergeben wir diese Sonderzeichen niemals an Funktionen wie fwprintf (), sodass ich nicht verstehe, warum dies überhaupt relevant ist.

Wirklich schöner reduzierter Testfall @zanchey!

Wie installierst du DragonflyBSD? Ich habe es mit einer nächtlichen ISO und auch der ISO 4.4.3 (mit Virtualbox) versucht und konnte das Problem mit dem reduzierten Testfall fwprintf nicht reproduzieren.

Bearbeiten: Ich konnte auch Fish in 4.4.3 erstellen und installieren, und die Tests bestehen auch, mit Ausnahme der Notifier-Tests.

Der Testfall schlägt nur über SSH fehl - er funktioniert an der Systemkonsole in VirtualBox.

Oh wow. Verwenden Sie Vagrant?

Nein, einfach VirtualBox 5.0.20.

Ich werde das übernehmen, nachdem ich # 3406 als Duplikat geschlossen habe. Ich werde versuchen, die Zeit zu finden, um FreeBSD zu installieren, das Problem zu reproduzieren und es bei Erfolg weiter zu debuggen.

@ lhmwzy das ist wahrscheinlich das gleiche Problem wie # 3406. Zu Ihrer Information, ich habe das letztere Problem halbiert und es aufgespürt, um f2246dfb343bea19beb176fb2cc534f85513b2eb festzuschreiben.

Von meinem Update bis Ausgabe 3406 (beachten Sie, dass ich jetzt mit FreeBSD 12 anstatt mit DragonFly BSD arbeite):

Zu Ihrer Information, ich habe FreeBSD 12 installiert und kann dieses Problem reproduzieren. Der Grund, warum keiner der Schlüssel funktioniert, ist, dass die Standardschlüsselbindungen nicht in einem UTF-8-Gebietsschema eingerichtet sind:

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'

Es gibt auch andere Fehler wie alias: Name cannot be empty . Ich habe auch bestätigt, dass das Bauen aus git checkout f2246df~ das Problem nicht aufweist. Was mich als Autor dieser Änderung sehr überrascht.

Gute Arbeit bei der Suche nach dem Commit, bei dem das Verhalten auseinander ging. Mir ist jedoch nicht klar, was daran falsch wäre.

Es gibt auch andere Fehler wie Alias: Name darf nicht leer sein

@ krader1961 : Dies scheint das gleiche Problem zu sein. @floam saw: Anführungszeichen mit nur Variablen werden in ein leeres Argument aufgelöst. Dieser Fehler wird ausgegeben, wenn der Alias test -z "$name" fehlschlägt.

@faho , Ja, ich habe gerade diesen Alias-Funktionsfehler

Außerdem habe ich Debug-Anweisungen hinzugefügt und alle von uns verwendeten isw...() -Funktionen (z. B. iswalnum() ) geben das richtige Ergebnis für diese internen Token auf FreeBSD 12 zurück. Der Vorschlag, den jemand @zanchey gegeben hat Auf einer BSD-Mailingliste ist es nutzlos, unser eigenes iswalnum zu definieren.

Tatsächlich können Sie die var-Erweiterung innerhalb eines String-Problems mit doppelten Anführungszeichen mit einem UTF-8-Gebietsschema auf BSD ganz einfach reproduzieren:

$ 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

Es lohnt sich auf jeden Fall, sich eingehender mit den Vorgängen zu befassen, wenn Sie eine var-Referenz mit einem doppelten Anführungszeichen beenden. Alle obigen Beispiele funktionieren gut mit LC_ALL = C.

Ich habe mich geirrt, als ich vor einigen Stunden sagte, dass iswalnum() die richtige Antwort auf FreeBSD zurückgegeben hat. Ich habe diese Funktion in meiner Debugging-Ausgabe fälschlicherweise aufgerufen, bevor setlocale("") aufgerufen wurde. Das Verschieben dieser Debug-Ausdrucke zeigt, dass der 32-Code-Punkt-Block, der bei 0xFDD0 beginnt, bewirkt, dass iswalnum() und iswgraph() FreeBSD einen Wert anstelle des korrekten Werts Null zurückgeben, jedoch nicht GNU. Auf der anderen Seite gibt GNU fälschlicherweise eins für iswgraph() für die Zeichen für den privaten Gebrauch ab 0xF600 zurück, während FreeBSD korrekt null zurückgibt.

Es scheint also, als müssten wir unsere eigenen Wrapper um diese Funktionen implementieren, um unabhängig von der Plattform ein korrektes Verhalten zu erzielen. Ich muss ein wenig darüber nachdenken, wie ich das mit der minimalen Menge an zusätzlichem Code und verwirrenden Abstraktionsebenen machen kann.

Ich habe diesen FreeBSD-Fehler geöffnet. Wir müssen diese kaputte Implementierung noch umgehen.

Wir haben bereits das Muster festgelegt, dass der Fischcode fish_wcswidth() anstelle von wcswidth() . Wir haben dies als cppcheck-Regel verankert (siehe _.cppcheck.rule_). Wir könnten das Gleiche für die Funktionsfamilie isw...() tun. Aber ist das die beste Lösung? Es ist sicherlich am einfachsten zu implementieren. Hat jemand eine bessere Lösung?

PS: Ich bin geneigt, dieses Problem eher als "Verbesserung" als als "Fehler" zu klassifizieren, da wir über die Verbesserung von Fischen sprechen, um einen Fehler auf einer der von uns unterstützten Plattformen zu umgehen. Ja? Nein? Wen interessiert das? :Lächeln:

PPS, ich habe überprüft, dass das Überschreiben der Plattform mit iswalnum() dieses Problem unter FreeBSD 12 behebt.

Meine bevorzugte Methode wäre, das Verhalten zur Konfigurationszeit zu überprüfen und die Funktionen genau dann zu überschreiben, wenn sie in dieser Hinsicht nicht kompatibel sind.

Ich werde das Überschreiben der Plattformfunktionen nicht auf Autoconf-Tests basieren. Zuerst haben wir Instanzen von Distributionen gesehen, die in einer Version korrektes (oder falsches) Verhalten aufweisen und dann das Verhalten in einer nachfolgenden Version umdrehen. Eine für FreeBSD 10 erstellte Binärdatei sollte beispielsweise unter FreeBSD 12 weiterhin ordnungsgemäß funktionieren. Wenn wir unser Verhalten auf einen Autoconf-Test stützen, wird dies nicht behandelt. Zweitens sind die fraglichen Tests extrem billig, selbst wenn wir sie umschließen, um ein korrektes Verhalten sicherzustellen, und die Aufrufe der betroffenen Funktionen befinden sich nicht in kritischen Leistungsschleifen. Drittens benötigen wir eine der Hilfsfunktionen, die durch diese Änderung eingeführt werden, um sicherzustellen, dass Benutzer nicht nur Codepunkte (die auf meiner TODO-Liste stehen) in unseren internen Status einfügen.

Als ich die folgende Aussage in einem früheren Kommentar schrieb, hatte ich die beiden Distributionen umgekehrt:

Andererseits gibt GNU fälschlicherweise eins für iswgraph () für die Zeichen für den privaten Gebrauch ab 0xF600 zurück, während FreeBSD korrekt null zurückgibt.

Gemäß den Unicode-FAQ-Codepunkten sollen Punkte in den Bereichen für den privaten Gebrauch mit einem zugeordneten Glyphen klassifiziert werden (dh iswgraph() sollte einen zurückgeben), sind jedoch keine alphanumerischen Zeichen (dh iswalnum() sollten zurückgegeben werden) Null).

Es scheint mir, dass ein Autoconf-Test, der das Ergebnis von iswalnum () für einen dieser Werte überprüft, funktionieren würde.

FreeBSD-Binärpakete von Ports werden nicht für eine andere Bibliothek als das Ziel erstellt - dies bildet die Grundlage für die Funktionsweise aller unserer Tests zur Konfigurationszeit.

Dies bedeutet, dass die vom System bereitgestellte Funktion unter Linux und OS X, @ krader1961, unnötig überschrieben wird.

Fish wird unter FreeBSD erstellt und dynamisch mit einer gemeinsam genutzten Bibliothek verknüpft:

$ 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)

Wollen Sie mit 100% iger Sicherheit sagen, dass sich die Versionsnummer von libc.so ändert, wenn sich das Verhalten des Gebietsschemasubsystems ändert? Ich habe weder die Zeit noch die Neigung, diese Frage zu untersuchen. Ich wäre eher konservativ, da mein Fix das Verhalten oder die Leistung von Fischen nicht merklich beeinflusst.

Wollen Sie mit 100% iger Sicherheit sagen, dass sich die Versionsnummer von libc.so ändert, wenn sich das Verhalten des Gebietsschemasubsystems ändert?

"nicht unser Problem".

"nicht unser Problem"

Natürlich ist es unser Problem. Dies ist der Grund, warum wir fish_wcswidth() und ähnliche Problemumgehungen für fehlerhafte Implementierungen haben.

Der Fehler liegt im localedef-Tool, das die ctype-Dateien generiert, und stammt von Illumos. Hier auf DF behoben:

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

@ Jrmarino : Danke für die Info! Wissen Sie, wann dies in die verschiedenen Betriebssysteme gelangt? Erhalten DFs Änderungen bereits Benutzer?

Vielen Dank Taufe! Ich habe gerade ein Upgrade auf FreeBSD 11.0-RELEASE-p1 durchgeführt und das ist wirklich ärgerlich. Wissen Sie, ob oder wann der Patch in FreeBSD 11.0-RELEASE integriert wird?

Beachten Sie, dass wir diesen Fehler bei Fischen umgehen, die aus Git-Kopf gebaut wurden. Wenn Sie immer noch Probleme mit Fischen von Git Head auf BSD haben, lassen Sie es uns wissen. Die Problemumgehung ist nicht in Fish 2.3.1 oder einer früheren Version enthalten, sondern wird in der kommenden Version 2.4.0 enthalten sein.

Die Änderung ist eher in sich geschlossen - sollte für alle Betreuer da draußen leicht zu portieren sein.

Bereits in der Codeüberprüfung.
https://reviews.freebsd.org/D8148

Großartig.

@shanavar Ich werde nach 1 Monat zusammenführen, da die Änderung ziemlich aufdringlich ist und ich sicherstellen möchte, dass es keine Nebenwirkungen gibt. Sobald dies validiert ist, werde ich eine Errata für 11.0-RELEASE anfordern, was bedeutet, dass Sie sie in ungefähr einem Monat + erwarten können

Das Kompilieren von Fisch aus Git funktioniert für mich unter 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

Fügen Sie dann /usr/local/bin/fish zu /etc/shells und führen Sie chsh -s fish , um Ihre Shell in Fish zu ändern.

Ich war also nicht der einzige mit diesen Problemen. Ich danke Ihnen allen für die Korrektur, das hat mich verrückt gemacht.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen