Created attachment 36012 [details]
konsole -e mc

I'm not able to reproduce on current trunk. Could this be fixed after 4.3 or could it be a configuration issue?

I've written some example C code to trigger the bug.  It's getting the terminal size using the TIOCGWINSZ ioctl to get the terminal size.  The TIOCGWINSZ ioctl call reports the correct size only when not using Konsole's -e option.  With the -e option, the size is always reported as 0x0:

#include <stdio.h>
#include <sys/ioctl.h>
#include <termios.h>

int main( void )
{
	struct winsize size;
	size.ws_col = size.ws_row = 0;
	if (ioctl(0, TIOCGWINSZ, &size) < 0) {
		printf("Error: ioctl failed.\n");
		return 1;
	}
	printf("Terminal size: %dx%d\n", size.ws_col, size.ws_row);
	printf("[ENTER to quit.]");
	scanf("%*[^\n]");
	return 0;
}

Your test program reports 0x0 every time, and I can confirm jumbled layouts for mc when run for the first time with a given Konsole size. (And for FrobTADS, where I first noticed the bug.)

The bug still persists in KDE 4.3.2. No interest in fixing this one? :-/

It works on my 4.3.2 machine and trunk.

konsole -e mc

SO what is different?

mc 4.7.0-pre3

I posted an example C program. Please use that. It demonstrates Konsole's failure to return the correct size.

The bug is still there in all 4.3.x versions as well as the 4.4 RCs and (the currently tagged but unreleased) 4.4.0.

related to Bug 176902 ?

and Bug 173999 ?

Issue persists with KDE 4.6 RC (4.5.90).

Issue persists in KDE 4.6 final.

Also, could someone please the status that still says "UNCONFIRMED"? It has been confirmed two years ago already.

I see this bug in KDE 4.6.1 (kubuntu PPA packages) and have some experimental data showing that it is a race condition.

First, I tried 'konsole -e mc' on two machines and only one of them (an older and slower one) showed the bug (9 times out of 10). I've  found that a reliable test is not with mc but with stty. To reproduce, run

  konsole --hold -e stty -a

The first line of stty output (appearing in a new konsole window) is:

  speed 38400 baud; rows 0; columns 0; line = 0;

which is obviously wrong. What is interesting is that if I add a small delay before stty, like this:

  konsole --hold -e sh -c 'sleep 0.1 && stty -a'

I get the correct output from stty:

  speed 38400 baud; rows 30; columns 80; line = 0;

Adding a similar delay before mc invocation also fixes this bug (on the machine where mc is affected).

My guess is that 'konsole -e ...' launches the command before its pseudo-terminal is fully set up, and then reports the 0x0 terminal size for some period of time. Later (when the konsole window fininshes its initialization) the PTY is filled with correct dimensions but it's too late if the application has already read the  terminal size from the PTY.

(In reply to comment #14)
> My guess is that 'konsole -e ...' launches the command before its
> pseudo-terminal is fully set up, and then reports the 0x0 terminal size for
> some period of time. Later (when the konsole window fininshes its
> initialization) the PTY is filled with correct dimensions but it's too late if
> the application has already read the  terminal size from the PTY.

I agree. The following app will query the window size repeatedly; only the first time will report the 0x0 size.

#include <stdio.h>
#include <sys/ioctl.h>
#include <termios.h>

int main( void )
{
    struct winsize size;
    for (;;) {
        size.ws_col = size.ws_row = 0;
        if (ioctl(0, TIOCGWINSZ, &size) < 0) {
            printf("Error: ioctl failed.\n");
            return 1;
        }
        printf("Terminal size: %dx%d\n", size.ws_col, size.ws_row);
        printf("[ENTER to continue, Ctrl+D to quit.]");
        if (getchar() == EOF)
            return 0;
    }
}

I guess konsole should init its pty info from its startup geometry, but I haven't looked what the code for this looks like.

Issue still there in 4.6.4.

Can somebody explain why this is still marked as UNCONFIRMED?

I think this bug can be marked as `new' now.

As pointed out by Sergei in comment #14, there exist a race condition. The initial window size of the Pty is 0x0, which will be updated to proper value after the TerminalDisplay widget get resized. However, current code can't guarantee the terminal process(shell, mc, etc) is started ONLY AFTER the first resizeEvent of TerminalDisplay widget has happened.

Application::createSession(...)
{
  ....
  view->createView(session);
  session->run();
  .....
}

Pty::start(...)
{
  ....
  pty()->setWinSize(_windowLines, _windowColumns);
  kDebug() << _windowColumns << "x" << _windowLines ;
  KProcess::start();
  ...
}

*** Bug 269470 has been marked as a duplicate of this bug. ***

Git commit 7e00edd5166096feb59ffa694b6a6ff858fe1924 by Kurt Hindenburg.
Committed on 05/08/2011 at 16:40.
Pushed by hindenburg into branch 'master'.

Make sure pty device has right size before terminal process queries it.

Whenever TeminalDisplay is resized, konsole tells the underlying
pty device its new size by calling Pty::setWindowSize(). However,
current code can't guarantee when the terminal process starts and
queries the pty device about its size, the pty device already has the
right info. This has caused some long known bugs, such as #176902.

This patch tries to guarantee that important assumption. It currently
uses a hard-coded small delay, which works pretty well in practice
although not that elegant.

Patch by Jekyll Wu <adaptee@gmail.com>

I think this is better than leaving the situation as it is.  This may
be backported if no issues are found.
BUG: 173999
BUG: 176902
BUG: 203185
BUG: 229058
REVIEW: 102061
FIXED-IN: 4.8

M  +7    -0    src/Emulation.h
M  +0    -1    src/Application.cpp
M  +1    -0    src/Session.cpp
M  +30   -6    src/Emulation.cpp

http://commits.kde.org/konsole/7e00edd5166096feb59ffa694b6a6ff858fe1924