Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
X-Sender: @ (Unverified)
Date: Wed, 26 Oct 2005 05:37:15 +0200
To: cygwin AT cygwin DOT com
From: Arend-Jan Westhoff <jpmcyafvmhsl AT spammotel DOT com>
Subject: Re: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005   11:54:34
In-Reply-To: <20051024133259.GA24278@calimero.vinschen.de>
References: <dj91f2$rbd$1 AT sea DOT gmane DOT org>  <A4E3891E681AC442BDC781C89393235901BFD874 AT d10sm004 DOT de10 DOT cocreate DOT com>  <20051020144227 DOT GB28514 AT trixie DOT casa DOT cgf DOT cx>  <dj91f2$rbd$1 AT sea DOT gmane DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <20051026033721.9D13C268F@dot.warande.net>

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
>> >>enter:
>> >>
>> >>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.
>
>
>Corinna

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.)
Results:
 	ls [zZ][zZ]
produces:
 	ZZ
So no case change: I cannot reproduce the problem.
 	cat zz
produces:
 	yy
Which shows the edit action was successful.

Could this for once mean a positive press for text mounts? Or has it
something 
to do with NTFS <-> FAT32 ?
How come that if I have text mounts the edit action in the preceding
procedure 
only ads a linefeed but no carriage return?
 	dump zz
produces:
 	zz:
 	00000000  7979 0a                                 yy.
Ah, because vim has default fileformats=unix,dos instead of dos,unix!

My cygcheck.out is still the same: 
<http://cygwin.com/ml/cygwin/2005-10/txt00018.txt>

Though I cannot reproduce the problem I do support those who experience it
and 
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
clearly 
 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
the 
 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 
 output.)
 (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
filename 
 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
 produces:
	zz
 but
 	cmd /c dir /B zz
 produces
 	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
usually 
not difficult to organize a directory so that TAB or SHIFT-TAB find the
desired 
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:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/