X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Matthew Woehlke <mw_triad AT users DOT sourceforge DOT net>
Subject:  Re: Escape colour codes
Date:  Wed, 04 Apr 2007 15:23:43 -0500
Lines: 37
Message-ID: <ev11gf$hmq$1@sea.gmane.org>
References:  <etlt2v$aq0$1 AT sea DOT gmane DOT org> <euuhri$f63$1 AT sea DOT gmane DOT org> <euuih2$iro$1 AT sea DOT gmane DOT org> <euvkme$hv0$1 AT sea DOT gmane DOT org> <4613A562 DOT 5090806 AT byu DOT net> <ev0ff8$bbu$1 AT sea DOT gmane DOT org> <loom DOT 20070404T212717-932 AT post DOT gmane DOT org>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0
In-Reply-To: <loom.20070404T212717-932@post.gmane.org>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Eric Blake wrote:
> The bug in all three of these programs is that they are adding spurious \1 into 
> the string passed to readline.  When you call readline("\001\001invisible\001
> \002plain"), then readline assumes that anything between the FIRST \001 and the 
> \002 is invisible (ie. special to the terminal instead of literal output).  So 
> readline thinks that it should PRINT the invisible string "\001invisible\001" 
> special to the terminal, followed by the visible string "plain".  However, as 
> you noticed, \001 is NOT special to the cmd.com terminal, and results in a 
> smiley face, and readline is now thoroughly confused (it thinks it is waiting 
> for input on position 6, but in reality it is waiting for input on position 8, 
> because you printed literal characters while claiming they were invisible).
> 
> Bash, on the other hand, DOES map \[ to the sequence '\001\001' inside of 
> parse.y's decode_prompt_string(), BECAUSE it later calls expand_prompt_string() 
> to get rid of the extra \001.  It needs to do this so that it can support 
> PS1='$(foo)' (the prompt is the expansion of command foo), and needed a way to 
> tell \[ and \] in PS1 apart from literal \001 and \002 resulting from the 
> expansion of other elements in the prompt string.  When the prompt is finally 
> expanded and ready to hand to readline, the extra \001 _used by bash_ is gone, 
> leaving only the SINGLE \001 _used by readline_.  In other words, the common 
> bug in all three programs you mentioned is that they copied bash's escape 
> sequences, but NOT bash's round of internal expansion, prior to calling 
> readline.  The comment in the lftp sources was rather revealing - if the coder 
> didn't know why bash used an extra \001, they shouldn't have copied that.

Given that three separate programs had *the same bug*, and given that 
bash is perhaps the most visible readline user, maybe it would be 
worthwhile to mention (briefly) in readline's doc to *not* copy bash's 
extra \001 in your own implementation? :-)

Anyway, I'm glad this was resolved without my (mis)help interfering too 
much. :-)

-- 
Matthew
"Will somebody get this walking carpet out of my way?!" -- Princess Leia 
Organa


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/