> > [EMAIL PROTECTED]:~> ls x* > > x.exe > > [EMAIL PROTECTED]:~> 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 [EMAIL PROTECTED]:~> 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.
> > [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 > > Agreed. I'll have to take a closer look into this, but it sure seems > related to the implicit addition of .exe. > > > [EMAIL PROTECTED]:~> 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 > > [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" > > 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. > > [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 > > 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'? > > [EMAIL PROTECTED]:~> ls x* > > x.exe > > [EMAIL PROTECTED]:~> 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. > > [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 > > 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/
