Re: coreutils-5.3.0-3

[Thomas Wolff <mined at towo dot net>]

> > 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?
I was aware that it's the shell, not cat, in this case, but I 
didn't notice that
me@host:~> cat > x.exe
exposes the same behaviour, and that bash -l does not show it 
(regardless of the terminal).
It's due to some difference in clobber settings, so forget this one.


> > 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.
On Linux (SuSE 9.0), it's different, but buggy too:
$ touch a
$ ln a b
$ mv -i a b
/bin/mv: overwrite `b'? y
$ ls a b
a  b
--> "a" should have been removed

On SunOS, it's fine:
$ touch a
$ ln a b
$ mv -i a b
mv: a and b are identical


> > 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".  ...
> ... it should have
> created y.exe leaving regular y alone.  Again, I'll have to look into it.
Agreed, "y.exe" is appropriate here.


> > 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.

Well, I had roughly the following statement in mind:
> This release retains cygwin patches to cp(1), install(1), ln(1), and
> mv(1), in order to more intelligently handle executables whether you typed
> the '.exe' or not.
and just thought that "rm" would belong to the basic set of 
"two-letter" file handling tools...

I think it would be acceptable in this case to just skip the 
prompt and continue right away with
/bin/rm: cannot remove `x': No such file or directory

Alternatively, if you implement the mapping here, also the prompt 
should be changed to
/bin/rm: remove regular file `x.exe'? 


> > 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: ...
Yes, the ls x* was just included to give a complete picture of the 
files that existed in the situation.
> 
> The confusion here is that `ls arg' lists arg under its command-line
> spelling, even if the command line omitted an implicit extension.
No, the confusion I mean is between the two different results of the 
"ls -i x" which doesn't use globbing.

> > 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.
For exact diagnostics (of which files exist), ls x* will probably be 
more obvious, intuitive, and thus more reliable.
And for meeting user expectancy, the option would not help as it 
would not normally be used. So I don't think the option would help.
If adding implicit ".exe" to ls output is not desired for 
compatibility (which may indeed be important not to break any scripts), 
what about:
$ ls x*
x  x.exe
$ ls x
x  x
--> This would be surprising as well on first glance, but maybe less 
confusing after all and easier to understand once the user thinks 
about the reason.


> But don't expect a fix any time soon;
> I will look at the other bugs before even considering extending ls.
That's fine. Thanks for the ".exe" magic anyway.

Kind regards,
Thomas

--
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/