You are not logged in.
I've been configuring i3 to open some programs when it starts, including a nano session running in xterm with some files open. I invoke xterm like "xterm -e nano (list of files)", which behaves seemingly randomly. Sometimes it works perfectly, sometimes it works but nano doesn't properly respond to the size of the window until I resize it (i.e. nano occupies a rectangle in the top left), sometimes nano uses the full width of the xterm but not the full height (again, until resizing), and sometimes the xterm closes after a split second, with the contents of the window being blank, like nano isn't even started.
The latter case doesn't happen when I just do "xterm -e nano", without opening any files with nano in particular, although that has the added oddity that sometimes I have to press ^X twice to exit, instead of once; the first time causes it to take up the full xterm and the second actually exits.
I also get the closing problem with "xterm -e bash -c 'nano (files)'", although it seems like it might be less common.
In all cases, the exit status of xterm is always 0, and I see no error messages anywhere. I couldn't find anything in the Xorg log.
I don't know whether to blame i3, xterm, or nano. I think there might be some subtlety of how xterm works that I'm missing here. Maybe it has to do with signals being handled incorrectly, since SIGWINCH seems to be received wrong (judging by the resizing problems mentioned above).
Last edited by 256 (2025-10-27 16:36:53)
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
I don't know whether to blame i3, xterm, or nano
nano. Or yourself.
Try
xterm -hold -e nano (files) to keep the TE open any maybe see some error message.
Is it possible that you're not properly quoting the files?
Offline
Try
xterm -hold -e nano (files)to keep the TE open any maybe see some error message.
With -hold, I just see a blank window when nano fails, same as when nano exits. No error message.
Is it possible that you're not properly quoting the files?
I don't think that's a problem. Here's an example invocation (the file could be anything, this is just an example, and also I forgot to mention that this problem occurs even when there's only one file being opened):
xterm -e nano .xinitrcThe man page says this is the right way to use -e. I feel like I must be getting something wrong here, though. I haven't had any luck reproducing this problem with other programs, so maybe you're right that nano (or me) is the problem.
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
nano possibly requires some minimal window size?
Is
xterm -geometry 128x25 -e nano .xinitrcbetter?
Offline
nano possibly requires some minimal window size?
It doesn't seem to be that. -geometry does nothing, but to test that, I modified my i3 config to make all xterm windows floating by default, instead of tiling:
for_window [class="XTerm"] floating enableThat completely got rid of the problem, although it's not what I want. So this must have something to do with i3 resizing the window.
... Oh! I just looked at journalctl and found the problem:
Oct 27 07:48:10 (hostname) systemd-coredump[321429]: [?] Process 321427 (nano) of user 1000 dumped core.
Stack trace of thread 321427:
#0 0x0000559f1943b6aa n/a (/usr/bin/nano + 0x86aa)
#1 0x0000559f19469ba5 n/a (/usr/bin/nano + 0x36ba5)
#2 0x0000559f194416b5 n/a (/usr/bin/nano + 0xe6b5)
#3 0x0000559f19441c52 n/a (/usr/bin/nano + 0xec52)
#4 0x0000559f19437c0e n/a (/usr/bin/nano + 0x4c0e)
#5 0x00007ff2f5627675 n/a (libc.so.6 + 0x27675)
#6 0x00007ff2f5627729 __libc_start_main (libc.so.6 + 0x27729)
#7 0x0000559f1943a6e5 n/a (/usr/bin/nano + 0x76e5)
ELF object binary architecture: AMD x86-64Now to try and figure out how to file a bug report. Can anyone else reproduce this issue?
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
https://wiki.archlinux.org/title/Debuginfod
https://savannah.gnu.org/bugs/?group=nano
No nano.
Workaround
xterm -e bash -c "sleep 0.1; exec nano (files)"("exec" will replace the bash process so the terminal should™ quit w/ nano)
Offline
Workaround
xterm -e bash -c "sleep 0.1; exec nano (files)"("exec" will replace the bash process so the terminal should™ quit w/ nano)
This workaround works perfectly, correct size and all. The exec is redundant though, it already exits when nano exits.
Using debuginfod with gdb gives this stack trace:
Program terminated with signal SIGFPE, Arithmetic exception.
Downloading 21.75 K source file /usr/src/debug/nano/nano-8.6/src/browser.c
#0 0x00005639d24c16aa in browser_refresh () at /usr/src/debug/nano/nano-8.6/src/browser.c:142
142 for (size_t index = selected - selected % (usable_rows * piles);
(gdb) bt
#0 0x00005639d24c16aa in browser_refresh () at /usr/src/debug/nano/nano-8.6/src/browser.c:142
#1 0x00005639d24efba5 in draw_all_subwindows () at /usr/src/debug/nano/nano-8.6/src/winio.c:3485
#2 0x00005639d24c6047 in block_sigwinch (blockit=true) at /usr/src/debug/nano/nano-8.6/src/nano.c:1041
#3 read_file (f=<optimized out>, fd=fd@entry=3, filename=filename@entry=0x563a100925f0 ".xinitrc",
undoable=false) at /usr/src/debug/nano/nano-8.6/src/files.c:691
#4 0x00005639d24c7e77 in open_buffer (filename=<optimized out>, new_one=<optimized out>)
at /usr/src/debug/nano/nano-8.6/src/files.c:467
#5 0x00005639d24bdc0e in main (argc=2, argv=0x7ffe6e3719a8) at /usr/src/debug/nano/nano-8.6/src/nano.c:2579
(gdb) p selected
$1 = 0
(gdb) p usable_rows
$2 = 0
(gdb) p piles
$3 = 0So as I suspected, it has to do with SIGWINCH. In particular it looks like a divide by zero if SIGWINCH happens whilst a file is being read. Is this enough information for a bug report to the nano devs (or just dev, singular, since it seems to be one person)?
EDIT: I found a way to reproduce this bug without a tiling window manager (at least it probably works without one). Open an xterm window and run "nano <(sleep 100)". If you press ^C without resizing the xterm, it simply cancels loading, but if you resize it before pressing ^C, you get a coredump.
Last edited by 256 (2025-10-27 09:27:54)
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline
Is this enough information for a bug report to the nano devs
If not you should seriously consider switching to vim ![]()
Offline
I submitted the bug: https://savannah.gnu.org/bugs/index.php?67635
The developer provided a patch that fixes the crashing, albeit not the resizing issue, so I'm marking this as [SOLVED]. At least for now, I am not switching to vim.
EDIT: I solved the resizing issue too.
EDIT 2: The fix for these bugs has made it into the core repos, so now it's solved for everyone.
Last edited by 256 (2025-11-13 21:57:20)
"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.
Offline