Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Sat, 21 Feb 2004 18:24:42 +0000
From: Robert R Schneck-McConnell <schneck AT math DOT berkeley DOT edu>
To: Cygwin List <cygwin AT cygwin DOT com>
Subject: Re: cp, install, and the .exe extension
In-Reply-To: <6.0.1.1.0.20040220141302.0391ba10@127.0.0.1>
References: <c13c7j$ue4$1 AT sea DOT gmane DOT org> <20040219232350 DOT GE23994 AT redhat DOT com> <c15jtg$jmj$1 AT sea DOT gmane DOT org> <6 DOT 0 DOT 1 DOT 1 DOT 0 DOT 20040220141302 DOT 0391ba10 AT 127 DOT 0 DOT 0 DOT 1>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2106405092-1077387882=:260"
Message-Id: <E1AubuT-000Msq-81@mk-smarthost-8.mail.uk.tiscali.com>

---559023410-2106405092-1077387882=:260
Content-Type: TEXT/PLAIN; charset=US-ASCII

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
---559023410-2106405092-1077387882=:260
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fileutils.patch"
Content-Disposition: attachment; filename="fileutils.patch"

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;


---559023410-2106405092-1077387882=:260
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="textutils.patch"
Content-Disposition: attachment; filename="textutils.patch"

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__



---559023410-2106405092-1077387882=:260
Content-Type: text/plain; charset=us-ascii

--
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/
---559023410-2106405092-1077387882=:260--