Mail Archives: cygwin/2005/03/10/10:30:45
> > 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?
I was aware that it's the shell, not cat, in this case, but I
didn't notice that
me AT 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 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.
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 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". ...
> ... 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 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.
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 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: ...
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 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.
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/
- Raw text -