[Top][All Lists]

[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: Wed, 2 Jul 2008 11:42:05 -0500

On Wed, Jul 2, 2008 at 11:10 AM, Micah Cowan <address@hidden> wrote:
> Hash: SHA1
> (My mailer is doing the quoting backwards again)
> Tom Scogland wrote:
>> On Thu, Jun 26, 2008 at 12:26 PM, Micah Cowan <address@hidden> wrote:
>> 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 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.
> You're right, of course: I was informed of this later, and sure enough,
> you're right.
> I like the direct check better, but I have to admit that "inappropriate"
> was a poor word to describe it.
> At least for the meantime, it's probably preferable to maintain
> consistency; we can always change it later.
>> 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.
> No, you were clear enough, it was me who was befuddled, sorry. I was
> thinking screen's "term" command works like vim's.
> You mention that the terminfo file is on the path in 3 separate places;
> what are those places? Where is terminfo looking when it finds (say) the
> xterm entry (look at the top line of the output from "infocmp xterm").
> Have you tried setting the TERMINFO env variable?

Fair enough mistake, anyway, interestingly enough, I actually just got
this working in gathering the answer to your questions, or at least to
the point where I can use the right term setting but there are still
some strange things going on.  So, it was in
/opt/local/share/terminfo/s/ and ~/.terminfo/s  but not in
/usr/share/terminfo/73 (the third place I mentioned, must have been
lost in an update...) anyway, the first two are normally searched, and
the second was the value of TERMINFO


but when I noticed it was missing from the default system terminfo I
copied it there and it works fine... Is it possible that on OSX
there's some kind of issue with interpreting TERMINFO or terminfo
paths that use the /<first letter>/ path scheme in screen? It seems
odd that my other apps do in fact take terminfo information from the
other two locations but screen does not.

Oh, and infocmp xterm returns the following.
#       Reconstructed via infocmp from file: /opt/local/share/terminfo/x/xterm
and for screen-256color-bce
#       Reconstructed via infocmp from file:

just more and more confusing...


> - --
> Micah J. Cowan
> Programmer, musician, typesetting enthusiast, gamer,
> and GNU Wget Project Maintainer.
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFIa6h27M8hyUobTrERAmvMAJ97IEoI2dVRb7cVJrvsrF4wrUkbVQCdG4WB
> swh5hAQNxcxzNpw62Dpdd3I=
> =brJZ

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]