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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
