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):
[EMAIL PROTECTED]:~> ls x* x.exe [EMAIL PROTECTED]:~> cat > x bash: x: cannot overwrite existing file --> should have created "x" which does not exist [EMAIL PROTECTED]:~> ls x* x.exe [EMAIL PROTECTED]:~> ln x y --> OK [EMAIL PROTECTED]:~> mv x y /bin/mv: cannot remove `x': No such file or directory --> misleading message [EMAIL PROTECTED]:~> mv -i x.exe y.exe --> should have prompted > ls y* y.exe > mv y.exe y /bin/mv: `y.exe' and `y' are the same file --> should have renamed [EMAIL PROTECTED]:~> ls x* y* x.exe y [EMAIL PROTECTED]:~> 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" [EMAIL PROTECTED]:~> ls x* x.exe [EMAIL PROTECTED]:~> 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 [EMAIL PROTECTED]:~> ls x* x.exe [EMAIL PROTECTED]:~> ls -i x 3659174697246106 x --> ^ this is actually "x.exe" [EMAIL PROTECTED]:~> touch x [EMAIL PROTECTED]:~> ls -i x 1970324836996817 x --> ^ now it's "x", a different file --> mapping inconsistent; maybe it should rather look like: [EMAIL PROTECTED]:~> ls x* x.exe [EMAIL PROTECTED]:~> ls x x.exe --> this is my proposal Kind regards, Thomas Wolff
