screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [screen-devel] couple of mac building issues, patch for one


From: Tom Scogland
Subject: Re: [screen-devel] couple of mac building issues, patch for one
Date: Thu, 26 Jun 2008 12:48:18 -0500

On Thu, Jun 26, 2008 at 12:26 PM, Micah Cowan <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]