This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cp error -- oh the great sanity of *nix tools?!?


The estimable Randall R Schulz <rrschulz@cris.com> responded Re: cp error --
oh the great sanity of *nix tools?!?


> Perhaps those two files _were_ the same. Namely, if make's current
> directory was /usr/sbin at time the cp commands were invoked.

I was not. I made sure of that in the Makefile script,  even had it print
out where it was to make sure.

> I don't believe cp reports that the source and destination files are the
> same unless they are. Surely you would rather it do this than open the
> destination with the create and truncate options and then copy the source
> (now empty) to it?
> Same as on any Unix, Linux, BSD, FreeBSD, AIX, HPUX or other Unix
work-alike.

Ahh, as it turns out, NOT. And therein lies this GOTCHA. Read on.

And  Mac ("Michael A. Chase" <mchase@ix.netcom.com>)  also wrote in his own
reply:

>Because Cygwin mounts allow the same directory to be reachable by
>different routes, it is not always obvious to the user whether two
>directories or files are the same. I guess the same could be true with
>symbolic links in normal UNIXs.

I guess, if I think about it for more than 1.8 sec I begin to get a headache
.. :-).

>Please confirm what directory make was working in when it tried to
>copy those files. The output from 'mount' is also needed to see if
>that directory and /usr/sbin/ are really the same directory.

They are not.

OK, all those who were in nearly intolerable suspense waiting for me to get
to the answer:

It's Cygwin, AND it' s `cp'. Yep. A most unfortunate interaction. To start
with, Cygwin's gcc automatically "maps" an output executable file with an
`.exe' extension filename. That's SO helpful, yes, and might usually be A
Very Good Thing. But NOT this time.

The files I was trying to copy SIMPLY DIDN'T EXIST in the directory I built
in. Because the names came from the Makefile code, but the actual files on
disk were $(PROGS).exe, that is ... each one has .exe caboosed to it ...
because of this I had to bang my head against the proverbial wall until I
saw exactly what was in the build directory.

It IS still  `cp' s fault, too. The message is cp's utterly unhelpful and
misleading way of telling me that the source files named as command
parameters don't exist -- and what the heck is THAT? That's a bona-fide BUG
if ever I was bitten by one. I am really astonished at this, in GNU
software.

                          * * * * * * * * * * * * * * * * * * * *

I have a fixed Makefile.IN prepared now for this package (Berkeley DB
2.7.7). This software's author (SleepyCat) will I am sure *never* be
interested in fixing his Makefile/configure setup for Cygwin, because it is
an old release. It is the highest-numbered 2.x release. I chose it because
the documentation that comes with Perl5.6.1/Cygwin says to do so (to use a
more recent bdb2.x that has the bdb1.xx-compatibility option, to not break
older Perl module code). So although it is an old package, it is IMHO *not*
irrelevent to Cygwin users (at least to those who might want to compile
their own Perl from source), since it is a Perl dependency. So, who is the
Maintainer of this sort of thing (Cygwin-Perl)? Can someone cite an
individual to whom I could forward my fixed Makefile.IN? So that it can be
incorporated into a package to add to the existing Cygwin-ported libraries?
I had to fix some of the code, too (all only macro stuff of course).

   Regards,
     Soren Andersen
   Cygwin Enthusiast

> At 19:58 2001-06-24, *I* wrote:
> >Dogma: GNU/*nix  programming is *always* so much better than what Redmond
> >can produce. Yeah, like.
> >
> >I am running a Makefile installation (`make install') and I keep getting
> >this error (the package is BerkeleyDB, this is irrelevent):
> >
> >
> >./db_checkpoint -> /usr/sbin/db_checkpoint
> >/usr/bin/cp: `./db_checkpoint' and `/usr/sbin/db_checkpoint' are the same
> >file
> >./db_deadlock -> /usr/sbin/db_deadlock
> >/usr/bin/cp: `./db_deadlock' and `/usr/sbin/db_deadlock' are the same
file
> >./db_dump -> /usr/sbin/db_dump
> >/usr/bin/cp: `./db_dump' and `/usr/sbin/db_dump' are the same file
> >./db_load -> /usr/sbin/db_load
> >/usr/bin/cp: `./db_load' and `/usr/sbin/db_load' are the same file
> >./db_printlog -> /usr/sbin/db_printlog
> >/usr/bin/cp: `./db_printlog' and `/usr/sbin/db_printlog' are the same
file
> >./db_recover -> /usr/sbin/db_recover
> >/usr/bin/cp: `./db_recover' and `/usr/sbin/db_recover' are the same file
> >./db_stat -> /usr/sbin/db_stat
> >/usr/bin/cp: `./db_stat' and `/usr/sbin/db_stat' are the same file
> >make: *** [install] Error 1
> >
> >You know, the hacker who wrote `cp' to give this error wording needs to
be
> >put up against a wall and *shot*.
> >
> >What does this mean? I am sure that this is "one of those things" that
> >everybody but me and two guys in Duluth seem to know.
> >
> >REALLY F*%$!)($! IRRITATED,
> >    soren andersen
> >
> >
> >
> >--
> >Want to unsubscribe from this list?
> >Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]