[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is direxpand available yet (to fix dirspell)?
From: |
John Caruso |
Subject: |
Re: Is direxpand available yet (to fix dirspell)? |
Date: |
Thu, 10 Jan 2013 18:57:15 +0000 (UTC) |
User-agent: |
slrn/0.9.7.4 (Win32) |
In article <mailman.17056.1357832272.855.bug-bash@gnu.org>, Chet Ramey wrote:
> On 1/9/13 1:27 PM, John Caruso wrote:
>> In article <mailman.16997.1357740561.855.bug-bash@gnu.org>, Chet Ramey wrote:
>>> 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.
[...]
>> 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.
Ok. When you said the filename was "rewritten with spelling correction
internally" I took your meaning to be that although it may look wrong
on the screen it was correct internally and so it would produce correct
results. But it sounds like you were really saying that although the
correct filename existed in some internal bash data structures, these
data structures never saw the light of day. From a user perspective that
seems like an invisible distinction, which is why I assumed you meant
the former and not the latter.
> 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.
For what it's worth, if you type $HOME/<partial-dir><TAB> in tcsh it will
complete <partial-dir> relative to $HOME but leave $HOME untouched. I
can see arguments for both ways, though I like how that behavior separates
path completion/spelling correction from inline variable expansion etc
(among other things it means that the command's history entry will still
reference the variable, so if the variable changes, executing the command
from history will pick up the new value).
- John
- Re: Is direxpand available yet (to fix dirspell)?, (continued)
Message not available