VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

Arend-Jan Westhoff
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 ( exactly in this spelling ).  If you
>> >>enter:
>> >>
>> >>vim ( also exactly in this spelling )
>> >>
>> >>and write it back after any modification, the file will be renamed even
>> >>to  
>> >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
name, so:)
 	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.)
 	ls [zZ][zZ]
So no case change: I cannot reproduce the problem.
 	cat zz
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?
 	dump zz
 	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
should be 
 done there.)
-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
line of 
 (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:
 	ls zz
 	cmd /c dir /B zz

Arend-Jan Westhoff.

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
file/dir quickly.
On bash you default get a beep and filename expansion stops whenever there 
is more than one choice. I hate that.

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list