VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34
Wed Oct 26 03:37:00 GMT 2005
At 15:32 2005-10-24 +0200, Corinna Vinschen wrote:
>On Oct 20 14:16, Shankar Unni wrote:
>> Christopher Faylor wrote:
>> >On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote:
>> >>Supposed, you have a file X.sh ( exactly in this spelling ). If you
>> >>vim x.sh ( also exactly in this spelling )
>> >>and write it back after any modification, the file will be renamed even
>> >>to x.sh.
>> >This isn't a vim problem. Windows filename handling is case-insensitive.
>> But I think it's worth mentioning that 6.3 doesn't do this (change the
>> case of the name when writing back). It overwrites the old file when
>> writing back, thus preserving its case.
>No, it doesn't. I just tried it in 6.3 and this behaviour is the same
>as in 6.4. There is special code in the native Windows port which tests
>explicitely for the case of the filename, but that's not in the UNIX
>code which is used for Cygwin.
I cannot reproduce this problem:
(Explanatory notes in (). If you don't need them please ignore them.)
The procedure creates or overwrites file ZZ:
(Should work on both cmd and Cygwin bash. On cmd must have
Cygwin\bin dir in PATH.)
"echo" -n ZZ > ZZ
("" relevance: Use Cygwin echo even on cmd. May be here not strictly
necessary, but instructive: In general also return and linefeed will be
executed when a vim script is sourced.)
(Please note that if a file like Zz preexisted that will still be its
rename ZZ ZZ
(At this point we have a file named: ZZ with contents: ZZ)
Now running one of the following two statements produces the same
results on my system:
vim +s/Z/y/g -s ZZ zz
vim +s/Z/y/g +wq zz
(Yes, I am violating the standard that files should end with newline, but
not relevant IMO.)
So no case change: I cannot reproduce the problem.
Which shows the edit action was successful.
Could this for once mean a positive press for text mounts? Or has it
to do with NTFS <-> FAT32 ?
How come that if I have text mounts the edit action in the preceding
only ads a linefeed but no carriage return?
00000000 7979 0a yy.
Ah, because vim has default fileformats=unix,dos instead of dos,unix!
My cygcheck.out is still the same:
Though I cannot reproduce the problem I do support those who experience it
want it changed because:
-I don't think changing it significantly impacts functionality on other OSs.
-Whether or not it is a vim bug is irrelevant. What is relevant that it is
undesirable behavior. (If vim is the appropriate place to change it it
-I think the rule should be that where ever a Cygwin utility uses a
filename of an
existing file it should use the actual name on disk and not the characters
user happened to type. (Wasn't that using something like: _findfirst() ?)
(So the dump statement above should not display zz: but ZZ: on its first
(Except of course where the user provides a new name as with the command:
rename, or when writing to a different file from vim. One can still use
completion to match an existing file's name if one wants to.)
Please note that my proposal is also in line with the native OS:
E.g. Cygwin "dir" and ls have such problem, the native cmd dir has not:
cmd /c dir /B zz
PS Speaking of filename completion: Windows can be configured to use TAB as
cmd file and directory expansion character. I do find the cmd filename
completion behaviour more convenient than the default bash version. It is
not difficult to organize a directory so that TAB or SHIFT-TAB find the
On bash you default get a beep and filename expansion stops whenever there
is more than one choice. I hate that.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin