[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: screen and curses problem
From: |
Miroslaw Dach |
Subject: |
Re: screen and curses problem |
Date: |
Wed, 4 Jul 2007 13:25:23 +0200 (CEST) |
Hi Thomas,
I have built ncurse using following commands:
./configure --host=i386-linux --with-normal --with-shared --without-debug
--without-profile --with-cxx --without-ada --enable-sigwinch
--enable-hard-tabs '--with-ospeed=unsigned int'
'--with-build-cc=/usr/bin/gcc -B/usr/bin/' CC=powerpc-405-linux-gnu-gcc
CXX=powerpc-405-linux-gnu-g++ CFLAGS="$CFLAGS -DPURE_TERMINFO -DSVR4_CURSES"
make -e HOSTCC="/usr/bin/gcc -B/usr/bin/"
I did not set tic anywhere.
Best Regards
Mirek
On Wed, 4 Jul 2007, Thomas Dickey wrote:
> On Wed, 4 Jul 2007, Miroslaw Dach wrote:
>
> > Hi Thomas,
> >
> > Thank you very much for your feedback. This what I see that the
> > crucial thing is the terminfo.
>
> Was that built using the target platform's tic?
> (I don't offhand know of a relevant bug - but if you're working fine now,
> we can revisit it if the current code's tic is a problem).
>
> > I have copied across that to my embedded system and it seems to be that
> > the problem has disappeared. I am even able to run the news version of
> > ncurses (5.6).
> >
> > Many thanks for all your hints.
>
> no problem
>
> >
> > Best Regards
> >
> > Mirek
> >
> > On Tue, 3 Jul 2007, Thomas Dickey wrote:
> >
> >> On Tue, Jul 03, 2007 at 02:06:08PM +0200, Miroslaw Dach wrote:
> >>> Hi Thomas,
> >>>
> >>> Thanks a lot for your hint. I have set the NCURSES_TRACE variable
> >>> to TRACE_MAXIMUM.
> >>>
> >>> Next what I did, I have started my server:
> >>> export TERM=linux-m
> >>> ../screen -t MYSERVER -d -m myServer
> >>
> >> ok. To make a comparison, I built a tracing ncurses and statically linked
> >> screen to that, calling trace(0xffff) from the main program. (I also
> >> turned on screen's debug feature, thinking I could get some separate
> >> tracing - find that screen writes to the same stream as ncurses's trace,
> >> perhaps because it assumes too much about the file descriptor).
> >>
> >>> The trace file looked like that:
> >>> ------------------------------------------------------------------------
> >>> TRACING NCURSES version 5.4.20050122 (tracelevel=0x1fff)
> >>> called {tgetent()
> >>> + called {setupterm("screen",1,0x7f9601e8)
> >>> your terminal name is screen
> >>> cannot open terminfo /root/.terminfo/s/screen (errno=2)
> >>> cannot open terminfo /usr/share/terminfo/s/screen (errno=2)
> >>> TERMPATH is /etc/termcap:/usr/share/misc/termcap
> >>> Adding termpath /etc/termcap
> >>> Looking for screen in /etc/termcap
> >>> cannot open terminfo /root/.terminfo/a/ansi-m (errno=2)
> >>> cannot open terminfo /usr/share/terminfo/a/ansi-m (errno=2)
> >>
> >> I've assuming there is some missing text here.
> >> If I force screen to read the termcap file, I get a very long listing
> >> showing the parsing of the termcap, e.g., text starting with
> >>
> >> TERMPATH is /tmp/BUILD/etc/termcap
> >> Adding termpath /tmp/BUILD/etc/termcap
> >> Looking for linux-m in /tmp/BUILD/etc/termcap
> >> Token: Names; value='dumb|80-column dumb tty'
> >> token: `dumb|80-column dumb tty', class 4
> >>
> >> That also fails (I'm not sure why at the moment - it is a long trace),
> >> with a
> >>
> >> Clear screen capability required.
> >>
> >> message.
> >>
> >> When it reads the terminfo, there's no "Looking for", etc.
> >> But there should still be some data:
> >>
> >> read terminfo /tmp/BUILD/share/terminfo/l/linux
> >> READ termtype header @0
> >> TERMTYPE name_size=20, bool=29/44, num=16/39 str=381/414(809)
> >> get Numbers[0]=-1
> >> get Numbers[1]=8
> >>
> >>> _nc_free_termtype(klone+acs|alternate character set for ansi.sys displays)
> >>> _nc_free_termtype(3u264v301w302x263y371z372{373|374}375~376.031-030054021+^P0333p3)
> >>> _nc_free_termtype(04r304y363z362{343|330}234)
> >>
> >> There's something wrong here - the parameter to _nc_free_termtype()
> >> should be a list of terminal names. In the two preceding calls,
> >> it looks like a fragment from an acsc string:
> >>
> >>
> >> acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
> >>
> >>> _nc_free_termtype(klone+sgr|attribute control for ansi.sys displays)
> >>> _nc_free_termtype(klone+color|color control for ansi.sys and
> >>> ISO6429-compatible displays)
> >>> _nc_free_termtype(linux|linux console)
> >>> _nc_free_termtype(linux-m|Linux console no color)
> >>> _nc_free_termtype(xf|xterm-xfree86|XFree86 xterm)
> >>> _nc_free_termtype(xterm-debian|xterm with modifications to follow Debian
> >>> keyboard policy)
> >>> _nc_free_termtype(xterm-redhat|xterm with modifications to follow Debian
> >>> keyboard policy)
> >>> _nc_free_termtype(v0|xterm|X11 terminal emulator)
> >>> _nc_free_termtype(ansi|ansi/pc-term compatible with color)
> >>> + + called {del_curterm(0x1006bb08)
> >>> _nc_free_termtype((null))
> >>> + + return }0
> >>> + return }-1
> >>> return }0
> >>
> >> These look ok - but as I noted, there seems to be something missing.
> >>
> >>> -----------------------------------------------------------------
> >>>
> >>> Next I have tried to attache to the server:
> >>>
> >>> screen -r
> >>>
> >>> trace file looked like that:
> >>> -----------------------------------------------------------------
> >>> called {tgetent()
> >>> + called {setupterm("linux-m",1,0x7f95fd18)
> >>> your terminal name is linux-m
> >>> cannot open terminfo /root/.terminfo/l/linux-m (errno=2)
> >>> cannot open terminfo /usr/share/terminfo/l/linux-m (errno=2)
> >>> TERMPATH is /etc/termcap:/usr/share/misc/termcap
> >>> Adding termpath /etc/termcap
> >>> Looking for linux-m in /etc/termcap
> >>> cannot open terminfo /root/.terminfo/a/ansi-m (errno=2)
> >>> cannot open terminfo /usr/share/terminfo/a/ansi-m (errno=2)
> >>> _nc_free_termtype(klone+acs|alternate character set for ansi.sys displays)
> >>> _nc_free_termtype(3u264v301w302x263y371z372{373|374}375~376.031-030054021+^P0333p3)
> >>> _nc_free_termtype(04r304y363z362{343|330}234)
> >>> _nc_free_termtype(klone+sgr|attribute control for ansi.sys displays)
> >>> _nc_free_termtype(klone+color|color control for ansi.sys and
> >>> ISO6429-compatible displays)
> >>> _nc_free_termtype(linux|linux console)
> >>> _nc_free_termtype(linux-m|Linux console no color)
> >>> _nc_free_termtype(xf|xterm-xfree86|XFree86 xterm)
> >>> _nc_free_termtype(xterm-debian|xterm with modifications to follow Debian
> >>> keyboard policy)
> >>> _nc_free_termtype(xterm-redhat|xterm with modifications to follow Debian
> >>> keyboard policy)
> >>> _nc_free_termtype(v0|xterm|X11 terminal emulator)
> >>> _nc_free_termtype(ansi|ansi/pc-term compatible with color)
> >>> + + called {set_curterm(0x10074c80)
> >>> + + return }(nil)
> >>
> >> Again, there's some missing data. For comparison here's a fragment of
> >> trace:
> >>
> >> called {tgetent()
> >> + called {setupterm("screen.linux",1,0xbfb229a8)
> >> your terminal name is screen.linux
> >> cannot open terminfo /users/tom/.terminfo/s/screen.linux (errno=13)
> >> read terminfo /tmp/BUILD/share/terminfo/s/screen.linux
> >> READ termtype header @0
> >> TERMTYPE name_size=37, bool=15/44, num=16/39 str=361/414(526)
> >> get Numbers[0]=80
> >> get Numbers[1]=8
> >>
> >>> screen size: terminfo lines = 4080 columns = 4103
> >>
> >> Those numbers don't make any sense to me (decimal/octal/hex):
> >>
> >> 4080: 4080 07760 0xff0 text "\017\360" utf8 \340\277\260
> >> 4103: 4103 010007 0x1007 text "\020\007" utf8 \341\200\207
> >>
> >> But I think that if you go back and isolate the apparent data overrun
> >> in the first command, that might give a clue.
> >>
> >>> Studding the output I see that LINES and COLUMNS are not correctly set.
> >>> Does ncurses detect that automatically?
> >>
> >> ncurses tries to use a system call for getting that information.
> >> But I think that's only a symptom - something is not using a
> >> correct buffer size (or structure size), and is overrunning some
> >> data. Rereading the database only gets worse.
> >>
> >>
> >
> > --
> > =============================================================================
> > Miroslaw Dach (address@hidden) - SLS/Controls Group
> > PSI - Paul Scherrer Institut CH-5232 Villigen
> > =============================================================================
> >
> >
>
>
--
=============================================================================
Miroslaw Dach (address@hidden) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
- screen and curses problem, Miroslaw Dach, 2007/07/03
- Re: screen and curses problem, Thomas Dickey, 2007/07/03
- Re: screen and curses problem, Miroslaw Dach, 2007/07/03
- Re: screen and curses problem, Thomas Dickey, 2007/07/03
- Re: screen and curses problem, Miroslaw Dach, 2007/07/03
- Re: screen and curses problem, Thomas Dickey, 2007/07/03
- Re: screen and curses problem, Thomas Dickey, 2007/07/03
- Re: screen and curses problem, Miroslaw Dach, 2007/07/04
- Re: screen and curses problem, Thomas Dickey, 2007/07/04
- Re: screen and curses problem,
Miroslaw Dach <=