On Thu, Jun 26, 2008 at 12:26 PM, Micah Cowan <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Scogland wrote: >> Hi, >> I've been a screen user for a few years on linux, but when switching >> to osx as my primary os not too long ago (long story...) I found the >> current development versions wont build. The issue was just a #ifdef >> that was checking the wrong item, patch attached. (sorry if this isn't >> the right place, given recent activity it seemed like the best idea) > > The patch doesn't look appropriate to me. Perhaps an explicit header > check in configure.in would be better?
Admittedly it might be, but the patch seemed appropriate as 'SVR4' rather than 'HAVE_SVR4_PTYS' is used to check all 3 other inclusions of that header. Thus my assumption was that it was a typo in pty.c that the wrong define was used, and thus a reasonable solution to make it match the 3 in process.c, screen.c and tty.c. If you'd like I can look into adding the additional check in configure.in for HAVE_SVR4_PTYS, but I have a feeling that's behaving correctly since osx does in fact have SVR4 style ptys (at least based on location/naming), but does not have other SVR4 support for some reason... not sure what's going on with that but there it is. > >> There is one other issue however that I'm having much worse trouble >> tracking down. On osx if I specify that screen should use >> screen-256color-bce as its TERM, it fails back to vt100 and all >> features disappear, once this happens I can't change screen's internal >> term through ^a:term it just sticks there. As a temporary measure I'm >> having it use xterm-256color, but I would like to find/fix the issue, >> if anyone knows where I might look for that it would be very helpful. >> Oh, and that term value works fine on linux and the terminfo file is >> in the path in 3 seperate places... so it shouldn't be a path issue. > > I've copied the screen-users list for this one (please send any > followups on this issue to the support list only). > > Are you running screen within another screen? If not, telling screen > that the host term is screen-256color-bce, is equivalent to lying to it, > and can't be supported. No, I'm telling it the host term is xterm-256color and in screenrc or on the command line telling screen that it should set its internal term variable, used for TERM in all shells run inside of screen, should be screen-256color-bce. Sorry that apparently wasn't clear, but the issue is that when setting the term to that value, which is normally perfectly valid, causes it to lock me into vt100 for the remainder of the session. The closest thing I have to a solution right now is telling everything running in screen that screen is a 256 color xterm, which is equivalent to lying to them as you put it. > > - -- > Micah J. Cowan > Programmer, musician, typesetting enthusiast, gamer, > and GNU Wget Project Maintainer. > http://micah.cowan.name/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIY9FO7M8hyUobTrERAvMjAKCK0qm6C0hTQ7tTc5+9KE0m5Gf2XgCfbg48 > HNKSMKchungXQSkS8Vva3xk= > =5qW9 > -----END PGP SIGNATURE----- > > > -- -N AKA:Tom Scogland I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Albert Einstein _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
