cp, install, and the .exe extension

cp, install, and the .exe extension

[Robert R Schneck]

This is a bug in the fileutils packaging (I think).

Recently I noticed that "install" has special handling for the .exe 
extension, and "cp" does not.  In the fileutils source tarball
I notice there are three files:
  copy.c  copy.c.cgf  copy.c.orig

If I replace "copy.c" with either of the other two and rebuild, I get a 
"cp" which *does* have special handling for the .exe extension.
Did the fileutils maintainer just forget to do this?

Incidentally, the Cygwin User's Guide specifically claims that "install" 
won't handle the .exe extension; but currently it does.

Robert


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

Re: cp, install, and the .exe extension

[Christopher Faylor]

On Thu, Feb 19, 2004 at 10:09:55PM +0000, Robert R Schneck wrote:
>This is a bug in the fileutils packaging (I think).
>
>Recently I noticed that "install" has special handling for the .exe 
>extension, and "cp" does not.  In the fileutils source tarball
>I notice there are three files:
>  copy.c  copy.c.cgf  copy.c.orig
>
>If I replace "copy.c" with either of the other two and rebuild, I get a 
>"cp" which *does* have special handling for the .exe extension.
>Did the fileutils maintainer just forget to do this?

No.

cgf

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

Re: cp, install, and the .exe extension

[Robert R Schneck]

Christopher Faylor <cgf-no-personal-reply-please@cygwin.com> wrote:
> On Thu, Feb 19, 2004 at 10:09:55PM +0000, Robert R Schneck wrote:
>>If I replace "copy.c" with either of the other two and rebuild, I get a 
>>"cp" which *does* have special handling for the .exe extension.
>>Did the fileutils maintainer just forget to do this?
>
> No.

Indeed.  Does this mean there is some reason that it is considered 
harmful to have cp do it, but appropriate to have install do it?
If so, can you explain?  I don't question, I'm just curious!

In any case, I'd like to put in a request to change the error message cp 
gives when "cp foo bar" is tried and only foo.exe exists.  
Currently it says
cp: `foo' and `bar' are the same file
which is needlessly obscure.

Robert


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

Re: cp, install, and the .exe extension

[Larry Hall]

At 01:33 PM 2/20/2004, Robert R Schneck you wrote:
>Christopher Faylor <cgf-no-personal-reply-please@cygwin.com> wrote:
>> On Thu, Feb 19, 2004 at 10:09:55PM +0000, Robert R Schneck wrote:
>>>If I replace "copy.c" with either of the other two and rebuild, I get a 
>>>"cp" which *does* have special handling for the .exe extension.
>>>Did the fileutils maintainer just forget to do this?
>>
>> No.
>
>Indeed.  Does this mean there is some reason that it is considered 
>harmful to have cp do it, but appropriate to have install do it?


Yes.


>If so, can you explain?  


No.


>I don't question, I'm just curious!


Yeah, sure...

OK, I'm just kiddin' you. ;-)  Think about a 'cp' that transparently handles 
'.exe' and a directory with 'foo' and 'foo.exe'.  You need to be able to 
copy both.  'install' is a special purpose utility.  Many projects that
use it to install don't consider that executables may require extensions on 
other platforms.  So they're written to just install 'foo'.  That causes
install failures.  It makes sense to "relax" the rules here, since it 
helps more than it hurts.  The reverse is true for 'cp' and other general 
purpose utilities.


>In any case, I'd like to put in a request to change the error message cp 
>gives when "cp foo bar" is tried and only foo.exe exists.  
>Currently it says
>cp: `foo' and `bar' are the same file
>which is needlessly obscure.


How about a patch instead of a request? ;-)


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


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

Re: cp, install, and the .exe extension

[Robert R Schneck-McConnell]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1384 bytes --]

On Fri, 20 Feb 2004, Larry Hall wrote:
[on changing the error message when cp can stat but not open a file
 due to .exe handling]
> How about a patch instead of a request? ;-)

Okay, attached.  I've also attached a textutils patch to enact my earlier
request that "cat > foo" create foo in the whatever mode Cygwin would
usually want, rather than always using text mode.


> OK, I'm just kiddin' you. ;-)  Think about a 'cp' that transparently handles
> '.exe' and a directory with 'foo' and 'foo.exe'.  You need to be able to
> copy both.  'install' is a special purpose utility.  Many projects that
> use it to install don't consider that executables may require extensions on
> other platforms.  So they're written to just install 'foo'.  That causes
> install failures.  It makes sense to "relax" the rules here, since it
> helps more than it hurts.  The reverse is true for 'cp' and other general
> purpose utilities.

As for being *able* to copy both foo and foo.exe, the special .exe
handling only occurs when *only* foo.exe exists.  So you certainly can
copy both.  As for install failures, I first started thinking about cp's
behavior due to a Makefile using cp rather than install.

That said, I do suppose the danger is less this way.

Hey, it might be interesting for managed mounts *really* to identify the
filenames "foo" and "foo.exe".  (Maybe they already do?)

Robert

[-- Attachment #2: fileutils.patch --]
[-- Type: TEXT/PLAIN, Size: 1221 bytes --]

diff -Nrup fileutils-4.1-2.old/src/copy.c fileutils-4.1-2.new/src/copy.c
--- fileutils-4.1-2.old/src/copy.c	2001-06-25 23:42:46.000000000 +0100
+++ fileutils-4.1-2.new/src/copy.c	2004-02-21 17:34:32.742569600 +0000
@@ -197,6 +197,14 @@ copy_reg (const char *src_path, const ch
   source_desc = open (src_path, O_RDONLY);
   if (source_desc < 0)
     {
+#ifndef __CYGWIN__
+      /* The following comment is incorrect.
+	 The code that would have deferred the same-name check until
+	 here is commented out in same_file_ok.
+	 So in most environments, errno == ENOENT will never happen. 
+	 In Cygwin, this happens because of the different
+	 handling of .exe in stat and open. 
+         The error message for non-ENOENT errors is probably better. */
       /* If SRC_PATH doesn't exist, then chances are good that the
 	 user did something like this `cp --backup foo foo': and foo
 	 existed to start with, but copy_internal renamed DST_PATH
@@ -205,6 +213,7 @@ copy_reg (const char *src_path, const ch
 	error (0, 0, _("%s and %s are the same file"),
 	       quote_n (0, src_path), quote_n (1, dst_path));
       else
+#endif
 	error (0, errno, _("cannot open %s for reading"), quote (src_path));
 
       return -1;


[-- Attachment #3: textutils.patch --]
[-- Type: TEXT/PLAIN, Size: 1213 bytes --]

diff -Nrup textutils-2.0.21.old/src/cat.c textutils-2.0.21.new/src/cat.c
--- textutils-2.0.21.old/src/cat.c	2001-12-01 17:29:26.000000000 +0000
+++ textutils-2.0.21.new/src/cat.c	2004-02-21 18:04:29.626361600 +0000
@@ -697,10 +697,13 @@ main (int argc, char **argv)
       file_open_mode |= O_BINARY;
       SET_BINARY (0);
 
+#ifndef __CYGWIN__
+      /* For Cygwin prefer default handling of text/binary on output */
       /* Setting stdin to binary switches the console device to
 	 raw I/O, which also affects stdout to console.  Undo that.  */
       if (isatty (STDOUT_FILENO))
 	setmode (STDOUT_FILENO, O_TEXT);
+#endif
     }
 #endif
 
@@ -727,6 +730,9 @@ main (int argc, char **argv)
 	    {
 	      int tty_in = isatty (input_desc);
 
+#ifndef __CYGWIN__
+	      /* For Cygwin prefer default handling of text/binary 
+		 on output */
 	      /* If stdin is a terminal device, and it is the ONLY
 		 input file (i.e. we didn't write anything to the
 		 output yet), switch the output back to TEXT mode.
@@ -735,6 +741,7 @@ main (int argc, char **argv)
 	      if (tty_in && optind <= argc)
 		setmode (STDOUT_FILENO, O_TEXT);
 	      else
+#endif
 		{
 		  SET_BINARY (input_desc);
 # ifdef __DJGPP__



[-- Attachment #4: Type: text/plain, Size: 218 bytes --]

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

Managed mounts and .exe files (Was Re: cp, install, and the .exe extension)

[Igor Pechtchanski]

On Sat, 21 Feb 2004, Robert R Schneck-McConnell wrote:

> [snip]
> Hey, it might be interesting for managed mounts *really* to identify the
> filenames "foo" and "foo.exe".  (Maybe they already do?)
>
> Robert

Huh?  What do you mean by "identify" here?  If you mean "equate", this
most likely won't happen.  If you mean "differentiate", then that's
already happening even on non-managed mounts (hence the need for special
cp and install hacks).  If you simply mean that *cp* (and install) should
not assume foo=foo.exe on managed mounts, then PTC. :-)

FWIW, WinNT/2k/XP allow executables to not have a .exe extension.

This does, however, bring me to an interesting observation about managed
mode mounts that I just thought of: since capital letters are encoded on
managed mounts, the underlying filesystem won't see "a.Exe" as an
executable file (nor, for that matter, "A.EXE").  Or, rather, it'll
probably be possible to execute it (especially on WinNT/2k/XP systems),
but using "./a.Exe", not "./a".  I know, I know, PTC, but I just wanted to
get this into the archives.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

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

Re: Managed mounts and .exe files (Was Re: cp, install, and the .exe extension)

[Robert R Schneck]

Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:
> On Sat, 21 Feb 2004, Robert R Schneck-McConnell wrote:
>> Hey, it might be interesting for managed mounts *really* to identify the
>> filenames "foo" and "foo.exe".  (Maybe they already do?)
>
> Huh?  What do you mean by "identify" here?  If you mean "equate", this
> most likely won't happen.  If you mean "differentiate", then that's
> already happening even on non-managed mounts (hence the need for special
> cp and install hacks).  If you simply mean that *cp* (and install) should
> not assume foo=foo.exe on managed mounts, then PTC. :-)

I mean, that Windows special handling of .exe be invisible on managed
mounts.  So "equate" in that the Cygwin filename "foo" might be 
the actual file "foo.exe", but certainly not preventing a Cygwin 
filename "foo.exe" as well (which might or might have the .exe extension
as an actual file).

This would require that the coding of filenames allow the Cygwin 
filename to have an .exe extension, independently of whether the actual 
file has the .exe extension.  Doubtless "chmod" would need to be able 
to change the actual filename when a file is made executable.

As for install etc *not* assuming foo=foo.exe, that should be possible 
just by making "stat" not perform the translation on managed mounts.  
(Presumably Cygwin tools which perform special .exe handling, perform it 
when they encounter a file which one can stat, but which returns "No 
such file" on open.)


> FWIW, WinNT/2k/XP allow executables to not have a .exe extension.

I wasn't aware of it, and haven't been able to figure it out in a couple 
of minutes of playing around and Googling.  How?

Certainly I observe that Cygwin executes .exe files differently; if I
rename a shell script to something.exe, it doesn't work very well at
all.

Robert


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

Re: Managed mounts and .exe files (Was Re: cp, install, and the .exe extension)

[Corinna Vinschen]

On Feb 21 23:07, Robert R Schneck wrote:
> Igor Pechtchanski <pechtcha@cs.nyu.edu> wrote:
> > FWIW, WinNT/2k/XP allow executables to not have a .exe extension.
> 
> I wasn't aware of it, and haven't been able to figure it out in a couple 
> of minutes of playing around and Googling.  How?

On NT, the CreateProcess call allows any name, also with no extension,
as executable file name.  Not so on 9x/Me.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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