[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is direxpand available yet (to fix dirspell)?
From: |
Chet Ramey |
Subject: |
Re: Is direxpand available yet (to fix dirspell)? |
Date: |
Thu, 10 Jan 2013 10:37:35 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
On 1/9/13 1:27 PM, John Caruso wrote:
> In article <mailman.16997.1357740561.855.bug-bash@gnu.org>, Chet Ramey wrote:
>> On 1/8/13 5:38 PM, John Caruso wrote:
>>> So just to verify: there's no way in bash 4.2.0 through 4.2.28 to make
>>> dirspell work correctly? The only fix is the direxpand option?
>>
>> Yes. Through 4.2.28, the dirspell option will cause the filename to be
>> rewritten with spelling correction internally, but the corrected filename
>> will not be rewritten on the command line.
>
> Huh--that's not what I'm seeing.
That's pretty much exactly what you're seeing:
> This is what I get from stock bash 4.2
> with no patches (and bash 4.2.10 and 4.2.24 behaved the same way):
>
> bash-4.2$ shopt -s dirspell
> bash-4.2$ ls /ect/passwd<TAB>
> /ect/passwd: No such file or directory
>
> The TAB there produces a space (and no bell) as though dirspell is in
> fact acting on the filename, but executing the command shows that bash
> is still using the misspelled filename internally.
We're saying the same thing, differently. The reason there is no bell and
the space is appended is because readline thinks the completion has
succeeded. The reason it thinks the completion has succeeded is because it
has -- bash has corrected ect to etc and told readline so. The difference
is that readline doesn't think it has to rewrite what appears in the actual
input buffer, because bash has not told it to do so. So readline gets
/etc/passwd back as a valid completion, verifies that's not a directory
and so appends a space and goes on. The input buffer doesn't get changed
and hitting return passes the still-uncorrected filename to ls.
> So as far as I can
> tell (and unless there's some other use case I'm missing), dirspell no
> longer worked from bash 4.2 through 4.2.28. And direxpand does indeed
> make dirspell work again (thanks for that)--in fact it seems like it
> doesn't do anything other than make dirspell work again.
It's more general than that. Having direxpand enabled tells bash (and,
indirectly, readline) that it's ok to rewrite what appears in the input
buffer to the form it uses internally to decide what to do about
completions. In the most common case, that means things like $PWD will
be expanded to the current directory, or $HOME will be expanded to your
home directory.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
- Re: Is direxpand available yet (to fix dirspell)?, (continued)
Message not available