bug-bash
[Top][All Lists]
Advanced

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

Re: Mailcheck during completion


From: Chet Ramey
Subject: Re: Mailcheck during completion
Date: Thu, 11 Aug 2011 10:44:57 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

On 8/11/11 10:35 AM, Martin von Gagern wrote:
> Hi Chet,
> 
> thanks for the swift reply!
> 
> On 11.08.2011 15:54, Chet Ramey wrote:
>> I suspect that you have a completion defined for `ls' and it's running a
>> command or process substitution that's causing the mail check.  Can you
>> run `set -x', then attempt the completion again and post the results?
> 
> Yes, there is a completion function for ls coming from the _longopt
> function from the bash-completion project at debian:
> http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=blob;f=bash_completion;h=66019379fe1e9ef9b1010bff53a0dc1baf4e73d9;hb=7c81ef895455d0f7543c65789ff62808e7465578#l1540
> 
> With -x enabled, I see several subprocess lines, i.e. lines indented by
> two + instead of one. Some triggered by eval, others by $(...).
> 
> I wonder why this breaks things. After all, those subshells should never
> print a prompt, should never even look for interactive input. But I take
> it you've got your reasons to suspect them. Can this be fixed?

It's hard to say without a better idea of the problem.  I suspected either
eval or command substitution because they cause re-entry into the shell
parser.  I don't suspect command substitution because that explicitly turns
off interactive mode, but eval does not.  I'll see if I can run something
simple to reproduce it.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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