cp, install, and the .exe extension

Robert R Schneck-McConnell schneck@math.berkeley.edu
Sat Feb 21 18:56:00 GMT 2004


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
-------------- next part --------------
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;

-------------- next part --------------
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__


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


More information about the Cygwin mailing list