[Solved] Incorrect terminal width running console programs inside TAsyncProcess

[FangQ]

I am trying to write a GUI for a command-line simulation tool I wrote (https://github.com/fangq/mmc).

In this command line tool, it prints a progress bar, with window width determined using ioctl(0, TIOCGWINSZ, &ttys);, see

https://github.com/fangq/mmc/blob/master/mmc/trunk/src/mcx_utils.c#L610-L616

This works well in Linux/Windows/Mac terminals. However, when I launch this command tool inside a TAsyncProcess, and capture the outputs and print them in a Tmemo, I found the command line program got confused on the width of the "console window". In the first pass of the above "mcx_progressbar()" call, it assumes a console width of 5230 (not sure why), and then it drops to 0 in all calls afterwards. This gives me extremely long buffer for printing the progress bar.

I set the TAsyncProcess.WindowColumns to 80, but this did not work, so were other tweaks of the options.

Is this a bug? or I should set something so that the console width info is passed on to the executable?

thanks

[Mr.Madguy]

I don't know. Check, what ttys contains before ioctl(0, TIOCGWINSZ, &ttys) call. Local variables are usually uninitialized and it seems like ioctl(0, TIOCGWINSZ, &ttys) simply fails, leaving garbage data in ttys.

[FangQ]

@Mr.Madguy, you are absolutely right! I found that was the cause of the problem. After initializing ttys to {0,0,0,0} and test if ttys.ws_col remains zero, I managed to define a default width.

thank you very much for the pointers!

[guest60499]

This works well in Linux/Windows/Mac terminals. However, when I launch this command tool inside a TAsyncProcess, and capture the outputs and print them in a Tmemo, I found the command line program got confused on the width of the "console window". In the first pass of the above "mcx_progressbar()" call, it assumes a console width of 5230 (not sure why), and then it drops to 0 in all calls afterwards. This gives me extremely long buffer for printing the progress bar.

If you are taking the console output and putting it directly into a text-only display, why are you writing a GUI? A lot of technical or scientific programs stay with a CLI interface not just because the developers are lazy or strapped for time, but because it's effective and concise.