Re: coreutils-5.3.0-3

[Eric Blake <ebb9 at byu dot net>]

-----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@host:~> ls x*
> x.exe
> me@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@host:~> ls x*
> x.exe
> me@host:~> ln x y
> --> OK
> me@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@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@host:~> ls x* y*
> x.exe  y
> me@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@host:~> ls x*
> x.exe
> me@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@host:~> ls x*
> x.exe
> me@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@host:~> touch x
> me@host:~> ls -i x
> 1970324836996817 x
> -->              ^ now it's "x", a different file
> --> mapping inconsistent; maybe it should rather look like:
> me@host:~> ls x*
> x.exe
> me@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@byu.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/