Re: XFCE freeze when opening file over NFS with Vim editor

[RVP <rvp%SDF.ORG@localhost>]

On Tue, 13 May 2025, Ramiro Aceves wrote:

> >  Does it happen:
> >  - With /usr/bin/vi on NetBSD (and matching "nvi" on Linux)?
>
> /usr/bin/vi in NetBSD does not crash (and do nothing, of course)
>
> >  - If you run vim from the xfce run dialog?
>
> if I try to execute  /usr/pkg/bin/vim it enters in thunar in /usr/pkg/bin 
> directory. Then I manually click on the vim executable and all XFCE desktop 
> freezes.
>
>
> >  - If you run vim from a different file manager such as pcmanfm-qt?
>
> Right clicking a text file and opening with vim says in terminal: Warning, 
> input is not from a terminal. It does not crash.
>
> If I execute vim by clicking on /usr/pkg/bin/vim,  pcmanfm-qt window 
> disappears and also terminal from which pcmanfm-qt was launched disappears.

I think I can explain all this: it's a Vim bug (+ maybe a getty(8) bug).

```
qemu$ tty
/dev/constty

qemu$ vim </dev/null >/dev/null
Vim: Warning: Output is not to a terminal
Vim: Warning: Input is not from a terminal
May 13 22:34:09 qemu init: getty repeating too quickly on port `/dev/constty', sleeping
May 13 22:34:39 qemu init: getty repeating too quickly on port `/dev/constty', sleeping
```

You can figure out what happened if you switch to another console and run
a `stty` on the broken one:

```
qemu# stty -f /dev/constty
speed 0 baud;
lflags: -icanon -isig -iexten -echo
iflags: -ixon -ixany -imaxbel -brkint
oflags: -oxtabs
cflags: -cread cs8 -parenb
discard dsusp   eof     erase   intr    kill    lnext   quit    reprint
<undef> <undef> <undef> <undef> <undef> <undef> <undef> <undef> <undef>
start   status  stop    susp    werase
<undef> <undef> <undef> <undef> <undef>

qemu#
```

In addition to the tty state being trashed, see the `speed 0 baud` setting. Vim
has done this when it didn't find a valid tty (the same thing, I presume, that
happens when you it via `Open with vim` in your file managers).

A `speed 0 baud` in Unix is used to signal "close this line". Looks like
getty(8) doesn't re-init this setting and you get init(8) complaining a lot
until you do:

```
qemu# stty -f /dev/constty $(stty -g -f /dev/ttyE1)
```

to init the line-state from another tty.

If, in your case, the tty the file managers run Vim on (with stdin/stdout
redirected elsewhere) is the one the X server is running on, then Bob knows
what havoc will result when that tty is revoke(2)'d when the server still is
running on it.

So, you should either configure the file managers to run vim like:

vim -g

if compiled with a GUI, or provide proper a terminal for it using a script
like:

```
#!/bin/sh
exec xterm -g 100x35 -e vim "$@"
```

(Depending on how the file manager run this script or cmd. line, you may have
to append a `&` to run it in the background.)

HTH,

-RVP