Fish is not operational on a vt220 terminal #2559

Closed
SirCmpwn opened this Issue Nov 23, 2015 · 56 comments

Projects

None yet

8 participants

@SirCmpwn

When running fish, no output is produced. It hangs.

@ridiculousfish
Member

You mean this guy? Do you have maybe more accessible steps to reproduce? :)

@krader1961
Member

I haven't seen a real Dec VT220 in well over a decade and given that they use RS232 I'd be really surprised to find one connected to a system running the fish shell. More details, please, such as the operating system. And if you're using a real VT220 how it's connected to the system. If you're using a terminal emulator then which one? What's your $TERM set to? When you say "running fish" do you mean that simply invoking "fish" hangs with no output, not even a shell prompt?

@zanchey
Member
zanchey commented Nov 24, 2015

I've got access to both a real DEC VT220 and a VT320 connected to machines which can run fish, and they worked fine with fish 2.1. The biggest issue is that if your locale is UTF-enabled then they can get quite confused by the extended characters.

Ours are connected to Linux via serial ports which have a getty process on the other end, thanks to a huge modernisation upgrade :-) where we threw out our LAT-based terminal service.

I'll try and swing past them on the weekend - the other questions that others have suggested are useful, but really I am interested in what version of fish you are running and what your locale is!

@ridiculousfish
Member

That's amazing @zanchey! What CPU do those DEC machines have? Does gcc run on it?

@zanchey
Member
zanchey commented Nov 24, 2015

We just use the DEC terminals as dumb terminals. They're hard to beat - still operating after 20+ years. The operating software is all in ROM AFAIK so I don't think you can run anything else directly on it.

If you'd like one, we have lots :-)

@SirCmpwn

Found the issue - $TERM was incorrect, and LANG=c helped as well. Thanks! For the curious, it is a real vt220, and I have it connected to Arch Linux (fully up to date, well, except for the hardware). It's connected with a DB29->DB9 null modem cable I made from a breadboard, a bunch of jumper cables, and a DB9 header, which is in turn connected to a simple RS232 USB serial cable.

@SirCmpwn SirCmpwn closed this Nov 24, 2015
@SirCmpwn

@ridiculousfish
Member

You made my day!

@SirCmpwn

Happy to help :)

@SirCmpwn

Hmm, correction - it works if I run it in tmux, but not without.

@SirCmpwn

As a workaround, I changed my shell to a script that launches tmux if TERM=vt220, otherwise fish.

@faho
Member
faho commented Nov 25, 2015

I don't think this is actually solved, so I'm reopening.

@faho faho reopened this Nov 25, 2015
@krader1961
Member

@faho Do you have the ability to reproduce this? Because without more data, and the ability to perform controlled experiments, I don't see how we're going to solve this. Having said that it seems really likely that this is due to one or more of the escape sequences that fish emits not being understood by a real VT220 and putting it into a weird state. For example, I ran

$ script
$ fish
$ exit
$ exit

and examined the resulting typescript file. I noticed there is the UTF-8 sequence \xe2 \x8f \x8e (down left arrow glyph or upside-down F) in the terminal initialization sequence that fish wrote before it wrote the prompt. That is almost guaranteed to confuse a device like a VT220.

@faho
Member
faho commented Nov 25, 2015

Do you have the ability to reproduce this?

I don't, but presumably @SirCmpwn does.

I noticed there is the UTF-8 sequence \xe2 \x8f \x8e (down left arrow glyph or upside-down F) in the terminal initialization sequence that fish wrote before it wrote the prompt.

And this is something that shouldn't be written with a non-UTF-8 $LANG. What was your value for that?

@SirCmpwn

Getting on a plane in a few hours, not bringing vt220 with me. Will happily test anything you've got once I get back (Saturday).

@SirCmpwn

I've been using LANG=C, fwiw.

@faho
Member
faho commented Nov 25, 2015

One thing I can think of is that we are still printing characters the vt220 can't understand in our functions - candidates being fish_prompt or fish_title (which should do a default thing if it's not defined). tmux might swallow that for us.

I'm not quite sure how to completely disable printing the title - this might need support in the C++ code.

Also, even with TERM=vt220 and LANG=C, it still seems to print underlined and bright characters - which may not be supported by an actual vt220 (dunno, that thing's older than I am).

@krader1961
Member

And this is something that shouldn't be written with a non-UTF-8 $LANG. What was your value for that?

That was with LANG=en_US.UTF-8. With LANG=C that UTF-8 sequence is replaced with "~.". Why either of those are appearing in the initialization sequences is perplexing.

I've also disabled fish_title and have a custom fish_prompt. I agree that those are likely candidates for causing mischief. Obviously we can't be responsible for customizations that emit sequences that confuse a VT220 but we should ensure that fish itself, including the stock functions, behave reasonably even with a terminal as old as a VT220. So the question is whether the problem occurs if fish is started with LANG=C and any custom functions that might emit incompatible sequences are disabled.

@krader1961
Member

Correction to my previous comment. With LANG=C a single tilde, "~", is inserted in place of the UTF-8 for code point 0x23CE (aka "return symbol"). Looking at the source I see that those characters are inserted by this statement in s_reset() in screen.cpp:

abandon_line_string.push_back(omitted_newline_char);

The symbol ommited_newline_char is defined in common.cpp. There comment in common.h says "Character representing an omitted newline at the end of text". I still don't understand why it's being inserted in the middle of the output of the s_reset() function but I'm guessing it has some utility in situations other than preparing to issue the first prompt.

I'm willing to bet $5 that if @SirCmpwn simply ensures LANG=C (or LC_ALL=C) before starting fish, and he uses a plain vanilla fish_prompt, his problem will disappear.

@zanchey zanchey self-assigned this Nov 26, 2015
@pickfire
Contributor

I think that LANG should be set to UTF or else there will be a lot of character that it can't display.

@krader1961
Member

I think that LANG should be set to UTF or else there will be a lot of character that it can't display.

Sorry, but that cannot be done if the output device (such as a VT220 terminal) does not support UTF-8. That's the whole point of this issue. Some devices cannot process UTF-8 and can be put into an inoperable state if they receive UTF-8 character sequences.

I should also point out that my previous comment was incomplete. In addition to ensuring only the stock fish prompt is used (or an alternative that is guaranteed to not emit non-ASCII chars) @SirCmpwn will probably also need to disable the fish title function via

function fish_title
end
@pickfire
Contributor

output device (such as a VT220 terminal) does not support UTF-8

Oh, so that's why LANG is set to c. My bad.

@zanchey
Member
zanchey commented Nov 27, 2015

Shockingly, our hardware has been upgraded! We've ditched the beautiful green VT320 for the classic orange of this dusty^Wshiny VT420!

Copyright 1989, Digital Equipment Corporation!

Both the 2.2.0 release and the current master build work fine:

fish 2.2.0 on vt420
fish 2.2.0-415-ga8a9ac0 on vt420

... although as you can see, autosuggestions are a little counterintuitive.

@SirCmpwn

Perhaps on a terminal with capabilities like these, the input could be bold and the suggestion normal?

@zanchey
Member
zanchey commented Nov 27, 2015

That does not look great.

@SirCmpwn

With every imaginable combination of environment variables, I still can't get fish to behave correctly. I made fish_title an empty function, too.

@krader1961
Member

On Mon, Nov 30, 2015 at 6:36 AM, Drew DeVault notifications@github.com
wrote:

With every imaginable combination of environment variables, I still can't
get fish to behave correctly. I made fish_title an empty function, too.

By "behave correctly" do you still mean that you see absolutely no output after starting fish? Not even the output of a command like "ls"? Regardless of the exact nature of the problem I'd like you to start fish within a script command to capture all of its output:

script
fish
echo hello
exit
exit

The filter the contents of the captured output through something like od -tx1z typescript and add that to this issue. I say "something like" because your version of od may not support the -z option in which case substitute -c.

@krader1961
Member

@SirCmpwn Will you be able to capture the output of starting fish in your problematic environment in the near future? Was there something about my suggested sequence of commands that is unclear or doesn't work? If your systems don't have the script command there are alternatives.

@SirCmpwn
SirCmpwn commented Dec 8, 2015

Sorry, I've been distracted. I'll give it a shot today.

@SirCmpwn
SirCmpwn commented Dec 9, 2015
00000000  53 63 72 69 70 74 20 73  74 61 72 74 65 64 20 6f  |Script started o|
00000010  6e 20 57 65 64 20 44 65  63 20 20 39 20 30 36 3a  |n Wed Dec  9 06:|
00000020  31 36 3a 35 35 20 32 30  31 35 0a 5b 73 69 72 63  |16:55 2015.[sirc|
00000030  6d 70 77 6e 40 71 62 20  7e 5d 24 20 66 69 73 68  |mpwn@qb ~]$ fish|
00000040  0d 0a 1b 5b 6d 1b 28 42  1b 5b 6d 1b 28 42 0d 20  |...[m.(B.[m.(B. |
00000050  0d 0d 0a 1b 5b 6d 1b 28  42 1b 5b 6d 1b 28 42 68  |....[m.(B.[m.(Bh|
00000060  65 6c 6c 6f 0d 0a 1b 5b  6d 1b 28 42 0d 20 0d 0d  |ello...[m.(B. ..|
00000070  0a 1b 5b 6d 1b 28 42 1b  5b 6d 1b 28 42 0d 0a 1b  |..[m.(B.[m.(B...|
00000080  5b 6d 1b 28 42 5b 73 69  72 63 6d 70 77 6e 40 71  |[m.(B[sircmpwn@q|
00000090  62 20 7e 5d 24 20 65 78  69 74 0d 0a 65 78 69 74  |b ~]$ exit..exit|
000000a0  0d 0a 0a 53 63 72 69 70  74 20 64 6f 6e 65 20 6f  |...Script done o|
000000b0  6e 20 57 65 64 20 44 65  63 20 20 39 20 30 36 3a  |n Wed Dec  9 06:|
000000c0  31 37 3a 31 31 20 32 30  31 35 0a                 |17:11 2015.|
000000cb

Looks like I'm able to type in and run commands, but the prompt doesn't show up.

@krader1961
Member

The data captured by the script command is perplexing. First, it doesn't contain anything that would confuse a DEC VT320 or VT420. There are no bytes with the high bit set and no escape sequences those terminals don't understand. Second, it shows that you apparently typed hello rather than echo hello yet there isn't any sort of error reported by the shell. Do you actually have a hello command on your system that does nothing, @SirCmpwn?

When you say "the prompt doesn't show up" do you mean that other output such as the Script started, output file is typescript from running the script command is visible? Are the commands you type visible as you type them? I don't know if english is your native language but details like that matter when trying to debug a problem of this nature.

Looking again at the most recent pictures uploaded by @zanchey it looks to me like the prompt is visible on his system. And I don't see any reason why it shouldn't be visible on yours. The only slightly odd thing I see is most of your prompt is apparently enclosed in square-brackets:

[sircmpwn@qb ~]$ 

But that in itself shouldn't cause any problems as those are all displayable ASCII characters.

P.S., It appears your login shell is fish. I didn't say so explicitly (an error on my part) but intended that you would login using something like /bin/sh in order to confirm that a non-fish shell works as expected. That's why I had you run the fish command after running script so as to switch to the fish shell.

@SirCmpwn

I typed "echo hello", promise. I don't have a hello command.

When you say "the prompt doesn't show up" do you mean that other output such as the Script started, output file is typescript from running the script command is visible? Are the commands you type visible as you type them? I don't know if english is your native language but details like that matter when trying to debug a problem of this nature.

English is my native language, and I meant exactly what I said. The fish prompt does not show up. I can type and see the characters echoed back.

The only slightly odd thing I see is most of your prompt is apparently enclosed in square-brackets:

That's my bash prompt. My login shell is a script that runs bash on a vt220 and fish otherwise. So I started this all from bash.

  1. Log in (bash)
  2. script
  3. "recording" message, dumped into bash shell
  4. fish (no prompt appears)
  5. echo hello (hello is printed)
  6. exit
  7. exit
@krader1961
Member

Thanks for the clarification, @SirCmpwn. With that in mind the data captured by the script command suggests at first glance that nothing written by fish to stdout is reaching the terminal, or fish is not writing to stdout. I say "suggests" rather than "it is certain" because the terminfo sgr0 (aka exit_attribute_mode) sequence is written more than once. The question is which program is writing those sequences: bash, fish, or both? Running

env SHELL=/bin/bash script
/bin/echo hello
exit

and examining the resulting typescript file I don't see the sgr0 sequence. Replacing bash with fish, however, does show that sequence in the captured data multiple times. So apparently the data from the writembs(exit_attribute_mode); statements in fish are reaching the terminal but nothing else is. Weird.

Too, it's clearly not a case of some weird escape sequence putting the terminal into a strange mode (e.g., by enabling the alternate character set). It's also clear that fish isn't really hung as you suggested in your first comment since it is responding to input and executing the commands entered.

Since the output of the echo command is displayed my first thought was that fish must be mangling the tty termios structure it uses when it is accepting input from the terminal; perhaps by mangling the baud rate. I would expect tmux to not pass such a change from its pty to the real tty which might explain why you don't see a problem when running fish inside tmux. But looking at the code I don't see any way that could happen. Not to mention that @zanchey can't reproduce your problem using a similar setup.

The terminfo escape sequences are written by writeb which simply calls out(b);. Things like the prompt text are written by writeb_internal which eventually calls write(1, &c, 1);. Where is the out function defined? Is it a C++ iostream function? What does out do differently from simply writing a byte array to stdout? Why would out(b); work but not write(1, &c, 1);? How in the world could running fish inside tmux alter the behavior?

@udnaan
udnaan commented Feb 18, 2016

I have the same issue although it's not a vt220, rather a microzed board running archlinux with fish 2.2. If I connect through ssh, everything is as it should be. However when I use serial console (SLAB_USBtoUART) no prompt appears. I'm able to type commands such as ls and the result is printed.

@SirCmpwn

I'm able to type commands such as ls and the result is printed.

Update from me, too: I can type in commands, but the text isn't echoed. Pressing enter will run the commands and the output appears normally.

@krader1961
Member

I don't know how much it will help us progress this issue but if you could run fish -d5 then execute a single command such as echo hello followed by exit perhaps the debug info will shed some light on the problem. Obviously you'll need to use the script command or some other means of capturing all the output. And if the diagnostic messages also don't appear on the console then use fish -d5 2> /tmp/fish.dbg.

@krader1961
Member

Also, if you're going to capture the fish debug output we might as well capture a syscall trace at the same time: strace -o /tmp/fish.strace -f -tt fish -d5.

@udnaan
udnaan commented Feb 18, 2016

There you go!

debug.zip
fish

@krader1961
Member

@udnaan: Thanks for those traces. It will take me a few days to analyze them. Mostly because I'm currently focused on fixing make test.

One thing that immediately caught my eye was the

fish: Exec job 'builtin source /usr/share/fish/config.fish 2>/dev/null' with id 1

at the top of the fish.dbg file. That tells me you're running a fish binary built at least a year ago (probably v2.2.0). Can you or anyone else (e.g., @SirCmpwn) install fish built from GitHub head and perform the same tests? Please also tell us what locale is in effect on your system; i.e., the output of locale. If it isn't a UTF-8 locale (and I'm betting it isn't) does forcing a UTF-8 locale fix this problem? For example, does creating a ~/.config/fish/config.fish file that contains

set -x LANG en_US.UTF-8

alter the behavior?

The "Wide character 57520 (\xE0B0) has no narrow representation" error is an issue. That is in a Unicode private-use character range that fish currently uses internally (something I'm working on improving). That could be adversely affecting the behavior of fish. That Unicode private-use code point could be the "rightwards black arrowhead" character which is used in the Powerline char set.

@SirCmpwn

Just got back from vacation. I keep my vt220 at work, will give this a shot tomorrow.

@zanchey zanchey removed their assignment Feb 25, 2016
@krader1961
Member

@udnaan: The "no narrow representation" error is because you're using oh-my-fish theme bobthefish in a non-UTF8 locale. The strace implies you've set your locale to en_US.UTF-8 but none of the supporting files are installed. I can see in the strace output that fish begins to write the prompt:

1482  18:57:29.156365 write(1, "\n", 1) = 1
1482  18:57:29.156596 write(1, "\33", 1) = 1
1482  18:57:29.156775 write(1, "[", 1)  = 1
1482  18:57:29.156946 write(1, "m", 1)  = 1
1482  18:57:29.157112 write(1, "\33", 1) = 1
1482  18:57:29.157276 write(1, "(", 1)  = 1
1482  18:57:29.157441 write(1, "B", 1)  = 1

Then nothing else is written to stdout. This is almost certainly because of the unicode char in your prompt that can't be serialized.

Please install the support files for locale en_US.UTF-8 or don't use non-ASCII chars in your prompt and don't set the locale to a UTF-8 variant.

@SirCmpwn: Do you think the above analysis might be applicable to your situation?

@SirCmpwn
SirCmpwn commented Mar 1, 2016

I don't think so, no, and I forgot to produce a log for you. For what it's worth I'm doing this a bit differently now and I'm not affected by the problem - but I can still reproduce and help narrow it down.

@udnaan
udnaan commented Mar 1, 2016

@krader1961 My apologies for not mentioning it earlier but the problem is specific to serial console. On ssh, everything works as expected.
Regardless, I fixed the unicode issue according to your advise but the issue on the serial console is still there.

@krader1961
Member

On ssh, everything works as expected.

That could be due to ssh propagating env vars to the remote machine. When you login via a RS-232C (serial) connection no env vars from your current session are propagated. What do you mean you "fixed the unicode issue"? What do you see when you run the locale command when ssh'ing in and via a serial connection? Is the output identical?

@udnaan
udnaan commented Mar 1, 2016

That's a good point. I don't have access to the board right now. Will check the output of locale and post the result tomorrow.

@krader1961
Member

@SirCmpn: When you say my analysis about unicode and locale isn't applicable to your situation I direct your attention to the comment you made last November 23. At this juncture I'm pretty confident that non-ASCII characters in an environment that is not unicode enabled are the problem. If I'm correct the question of whether fish can reasonably be expected to better handle this is TBD. Specifically, if the locale is set to a UTF-8 encoding that isn't supported by the platform is there anything fish can do to provide saner behavior.

@SirCmpwn
SirCmpwn commented Mar 1, 2016

I don't use oh-my-fish and I don't have a custom prompt, I mean. I'm confident that the locale is set to C on the terminal.

@zanchey zanchey added this to the fish-future milestone Mar 9, 2016
@zanchey
Member
zanchey commented Mar 9, 2016

I wonder if things are any better with TERM=dumb?

@krader1961
Member

FWIW, I'm am somewhat confident this is due to a non-C locale. A real VT220 has no support for a unicode locale. And if the fish locale is a unicode locale like en_US.UTF-8 then it will emit a UTF-8 sequence with every prompt and that is likely to cause problems.

See the wsetlocale() function in common.cpp. However, I haven't yet checked what the wcwidth() function returns for that wide-char in the C locale so it's possible that even setting the locale to "C" won't yet fix this problem.

@krader1961 krader1961 self-assigned this Mar 25, 2016
@krader1961 krader1961 removed this from the fish-future milestone Mar 25, 2016
@krader1961
Member

This is now four months old. I'm reluctant to close this as unresolved but if no one who has the requisite hardware cares enough to continue actively debugging this issue I don't know what else we can do.

I also investigated the question in my previous update and found that "~" rather than the \u23CE unicode "return" character will be emitted even when the locale is set to C in the config.fish file.

@udnaan
udnaan commented Mar 29, 2016

This is the output of the locale command:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8

I'm not sure what support files to install for UTF-8. The prompt works for over SSH.

Setting the LC_ALL to C emits the error about not having wide char support.

The set commands output over ssh:

COLUMNS 158
DBUS_SESSION_BUS_ADDRESS unix:path=/run/user/1001/bus
FISH_VERSION 2.2.0
HOME /home/nan
IFS \n\ \t
LANG en_US.UTF-8
LINES 37
LOGNAME nan
MAIL /var/spool/mail/nan
PATH '/home/nan/.fzf/bin'  '/usr/bin'  '/bin'  '/usr/sbin'  '/sbin'
PWD /home/nan
SHELL /usr/bin/fish
SHLVL 1
SSH_CLIENT '10.12.4.180 34635 22'
SSH_CONNECTION '10.12.4.180 34635 10.12.4.91 22'
SSH_TTY /dev/pts/0
TERM xterm-256color
TMPDIR /tmp
USER nan
XDG_RUNTIME_DIR /run/user/1001
XDG_SESSION_ID c5
_ set
__bobthefish_bg_job_glyph '% '
__bobthefish_branch_glyph 
__bobthefish_current_bg NONE
__bobthefish_detached_glyph ➦
__bobthefish_dk_brown 4d2600
__bobthefish_dk_green 0c4801
__bobthefish_dk_grey 333
__bobthefish_dk_orange 3a2a03
__bobthefish_dk_red 600
__bobthefish_hg_glyph ☿
__bobthefish_left_arrow_glyph 
__bobthefish_left_black_arrow_glyph 
__bobthefish_ln_glyph 
__bobthefish_lt_brown BF5E00
__bobthefish_lt_green addc10
__bobthefish_lt_grey ccc
__bobthefish_lt_orange f6b117
__bobthefish_lt_red C99
__bobthefish_med_blue 005faf
__bobthefish_med_brown 803F00
__bobthefish_med_green 189303
__bobthefish_med_grey 999
__bobthefish_med_red ce000f
__bobthefish_nonzero_exit_glyph '! '
__bobthefish_padlock_glyph 
__bobthefish_pypy_glyph ᵖ
__bobthefish_right_arrow_glyph 
__bobthefish_right_black_arrow_glyph 
__bobthefish_ruby_red af0000
__bobthefish_slate_blue 255e87
__bobthefish_superscript_glyph '¹'  '²'  '³'
__bobthefish_superuser_glyph '$ '
__bobthefish_virtualenv_glyph ◰
__fish_active_key_bindings fish_default_key_bindings
__fish_added_user_paths /home/nan/.fzf/bin
__fish_bin_dir /usr/bin
__fish_config_interactive_done
__fish_datadir /usr/share/fish
__fish_help_dir /usr/share/doc/fish
__fish_init_1_50_0
__fish_sysconfdir /etc/fish
fish_bind_mode default
fish_color_autosuggestion '555'  'yellow'
fish_color_command '005fd7'  'purple'
fish_color_comment red
fish_color_cwd green
fish_color_cwd_root red
fish_color_error 'red'  '--bold'
fish_color_escape cyan
fish_color_history_current cyan
fish_color_match cyan
fish_color_normal normal
fish_color_operator cyan
fish_color_param '00afff'  'cyan'
fish_color_quote brown
fish_color_redirection normal
fish_color_search_match --background=purple
fish_color_selection --background=purple
fish_color_valid_path --underline
fish_complete_path '/home/nan/.config/fish/completions'  '/etc/fish/completions'  '/us'…
fish_function_path '/home/nan/.config/fish/functions'  '/etc/fish/functions'  '/usr/sh'…
fish_greeting Welcome\ to\ fish,\ the\ friendly\ interactive\ shell\nType\ \e\[32mhe…
fish_key_bindings fish_default_key_bindings
fish_pager_color_completion normal
fish_pager_color_description '555'  'yellow'
fish_pager_color_prefix cyan
fish_pager_color_progress cyan
fish_user_paths /home/nan/.fzf/bin
history 'exit'  'set '  'echo '  'echo $LC_ALL'  'LC_ALL'  'locale'  'ls'  'fish'  'set LC_AL'…
status 0
umask 0022
version 2.2.0

output of set command over serial:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[nan@nanz ~]$ vi ~/.config/fish/
config.fish         fish_history
fishd.000a35000123  functions/
[nan@nanz ~]$ vi ~/.config/fish/config.fish
fish_color_history_current cyan
fish_color_match cyan
fish_color_normal normal
fish_color_operator cyan
fish_color_param '00afff'  'cyan'
fish_color_quote brown
fish_color_redirection normal
fish_color_search_match --background=purple
fish_color_selection --background=purple
fish_color_valid_path --underline
fish_complete_path '/home/nan/.config/fish/completions'  '/etc/fish/completions'  '/us'…
fish_function_path '/home/nan/.config/fish/functions'  '/etc/fish/functions'  '/usr/sh'…
fish_greeting Welcome\ to\ fish,\ the\ friendly\ interactive\ shell\nType\ \e\[32mhe…
fish_key_bindings fish_default_key_bindings
fish_pager_color_completion normal
fish_pager_color_description '555'  'yellow'
fish_pager_color_prefix cyan
fish_pager_color_progress cyan
fish_user_paths /home/nan/.fzf/bin
history 'exit'  'set'  'set '  'echo '  'echo $LC_ALL'  'LC_ALL'  'locale'  'ls'  'fish'  'set L'…
status 0
umask 0022
version 2.2.0
@krader1961
Member

@udnaan: a UTF-8 locale will not work very well if you're using something like a DEC VT-220 which does not support Unicode. Even if you set the locale to C (or POSIX) the resulting behavior is likely to be unpredictable if you have any non-ASCII characters in things like directory names.

Setting the LC_ALL to C emits the error about not having wide char support.

That should be fixed if you use a fish built from git head. The 2.2.0 release is known to have problems with the C locale when dealing with non-ASCII characters such as reporting unexpected encoding/decoding errors.

@udnaan
udnaan commented Mar 29, 2016

I'm not sure what to try next. Is there anything else that I can do to help debug?

@krader1961
Member

@udnaan: At this juncture the only way I can see to continue debugging this is to replace the hardware terminal with a modern terminal emulator such as iTerm2, Konsole, etc. by connecting a modern, UTF-8 aware, terminal via a network to RS-232 interface. This can be something like this USB to RS-232 converter or any of the numerous "terminal servers" which provide network access to devices which only have a RS-232 interface.

@floam
Member
floam commented Mar 29, 2016

I have ZOC (commercial with trial) and IVT (open source but Win32) waiting
for me at home, nabbed just before I left to dinner. Any good? Waste of time? I guess I shouldn't be surprised if it's no different than xterm in a strict mode of some sort. I'm hoping this will be like a console emulator where they are emulating hardware and I can feed it an original ROM, bugs and all, for it to run. We'll see...

ZOC I actually have a license for and it's great for headless servers and for things like trying to "jailbreak" a 35 year old Japanese wire-EDM machines that run PC98 with funny cons drivers modified to be really annoying. (Nothing nefarious - fixing 30 year old bugs and retrofitting FTP servers in, mostly).

But my hopes are low - if you want to see what a VT220 does you just go buy a VT220.

@krader1961
Member

Sorry, but I'm going to close this because it is now quite old and it doesn't look like anyone has the time or skills to get to root cause. If I was still as UNIX support engineer at IBM I'd have access to the necessary HW and would tackle this myself.

@krader1961 krader1961 closed this May 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment