Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <42305744.802@byu.net> Date: Thu, 10 Mar 2005 07:18:44 -0700 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Thomas Wolff CC: cygwin AT cygwin DOT com Subject: Re: coreutils-5.3.0-3 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Moving to cygwin list, where this belongs] According to Thomas Wolff on 3/9/2005 2:53 PM: > I have rechecked some inconsistencies with the magic ".exe" suffix > handling (see http://sourceware.org/bugzilla/show_bug.cgi?id=581) > with coreutils 5.3.0 and here is an updated summary of inconsistencies > and unexpected behavior (some issues resolved, some new ones appeared): > > > me AT host:~> ls x* > x.exe > me AT host:~> cat > x > bash: x: cannot overwrite existing file > --> should have created "x" which does not exist It works for me on WinXP using bash 2.05b-17 inside a cmd window: $ ls x* x.exe $ cat x.exe > x $ ls x* x x.exe You'll need to attach 'cygcheck -svr' output if you want more help diagnosing why you are seeing a failure. Also, note that it is not cat that (doesn't) create the file, but your shell. Which shell are you using, a plain Windows cmd, or a cygwin shell? If it is a cygwin shell, are you running it from cmd or from rxvt/xterm? > > > me AT host:~> ls x* > x.exe > me AT host:~> ln x y > --> OK > me AT host:~> mv x y > /bin/mv: cannot remove `x': No such file or directory > --> misleading message Agreed. I'll have to take a closer look into this, but it sure seems related to the implicit addition of .exe. > me AT host:~> mv -i x.exe y.exe > --> should have prompted > Agreed that this is the behavior required by POSIX. But it has nothing to do with .exe handling: $ touch a $ ln a b $ mv -i a b - --> Oops, last command didn't prompt I don't have access to a proper Unix box as I'm typing this, but I will try testing this on a Solaris box later today. It may be an upstream bug when reducing the link count. > > >>ls y* > > y.exe > >>mv y.exe y > > /bin/mv: `y.exe' and `y' are the same file > --> should have renamed Agreed that this is confusing, especially since `mv y.exe x' does do the rename to `x'. I'll have to look into this as well. But, as a workaround, you can use `mv y.exe y.', provided you are not in a managed mount (on a managed mount, it creates `y.', so you have to do a two-stage mv). > > > me AT host:~> ls x* y* > x.exe y > me AT host:~> cp -i x y > /bin/cp: overwrite `y'? y > /bin/cp: cannot create regular file `y.exe': No such file or directory > --> confusing message; should have created "y" Agreed that it is probably not correct, but I disagree with your conclusion that it should have created "y". I think that implicit .exe handling should intuitively work as follows - if the command line names a source file without the extension, but the directory only contains a file with the extension, then .exe is implicitly attached to both the source and destination. If the source file is named with the extension, then implicit extension behavior is bypassed. In your case, `cp -i x y' named x without the .exe, and no plain x exists, so it should be appending .exe to both x and y; from there, since y.exe does not exist, it should have created y.exe leaving regular y alone. Again, I'll have to look into it. > > > me AT host:~> ls x* > x.exe > me AT host:~> rm -i x > /bin/rm: remove regular file `x'? y > /bin/rm: cannot remove `x': No such file or directory > --> handling inconsistent; first, it maps, then no more Historically, I think that cygwin rm(1) has always required the extension, refusing to remove x.exe if you did not provide the extension. But the fact that the interactive question has figured out that .exe is needed is confusing, so I will probably have to patch rm. Do we want bestow implicit .exe behavior on rm, so that `rm x' removes x.exe if x doesn't exist? The answer to that question will affect my patch. > > > me AT host:~> ls x* > x.exe > me AT host:~> ls -i x > 3659174697246106 x > --> ^ this is actually "x.exe" Wait a minute - you used a glob in one place and not the other. Shell globbing picks up the .exe. Observe: $ echo x* x.exe $ echo x x $ ls x* x.exe $ ls x x The confusion here is that `ls arg' lists arg under its command-line spelling, even if the command line omitted an implicit extension. > me AT host:~> touch x > me AT host:~> ls -i x > 1970324836996817 x > --> ^ now it's "x", a different file > --> mapping inconsistent; maybe it should rather look like: > me AT host:~> ls x* > x.exe > me AT host:~> ls x > x.exe > --> this is my proposal So, maybe it is worth my time to see if I can make ls always list the extension, even when the extension was implicit. This is a backwards-incompatible change, and I don't really want to provide it as the default behavior. However, I might be willing to add a new cygwin-specific flag to ls. How about -e or --extension, which tells ls to list the implied extension. And also a companion switch, -E or - --no-exe which strips .exe unless there is another file in the same directory without the .exe. With options, you could always choose which behavior you get as a default by having a shell function or alias that uses the new option of your choice. But don't expect a fix any time soon; I will look at the other bugs before even considering extending ls. Provide your own patch if you really want this new option. > > > Kind regards, > Thomas Wolff > - -- Life is short - so eat dessert first! Eric Blake ebb9 AT byu DOT net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMFdD84KuGfSFAYARAs5LAKC8+OagCbVWzKNEwUzwYNG3A3VFqwCgwPZz XJXGg6Z0gnWn2ofCPcGNEPk= =IQ+z -----END PGP SIGNATURE----- -- 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/