I've used the same cp trick - assuming it would fail if the target
directory didn't exist (when I'm too lazy to check first).  I think there
is no question that this method is "better", but it's certainly not worth
sacrificing POSIX compliency.

I don't think anyone has mentioned the idea of introducing an option.  It
won't be the first instance that a "POSIX_MISTAKE" option has been
introduced.  It could either be a compile time option in namei,
and/or a flag for cp.  If a flag was added to cp which would verify the
target directory existed before creating a regular file - then individual
users could decide which behaviour of cp they want.  I admit adding an
option to cp doesn't "fix" the problem, but in conjunction with a compile
time option in namei (which should default to POSIX behaviour) - it should
make everyone happy.

Anyway, I'd be disgusted to see a piece of software that checks for an
existing file with a slash at the end.

Rick

On Sun, 11 May 1997, John F. Woods wrote:

> > Why is the POSIX way necessarily Right?  If POSIX requires this bizarre
> > behavior of cp, as described by several people, then I think POSIX is
> > broken badly enough that conformance to this aspect of it is not worth
> > the damage it requires.
> 
> Speaking as the original complainer here, to repeat a point that has been made
> dozens of times:  POSIX compliance makes it possible for implementors to write
> programs without caring what OS they're writing for; it makes it possible for
> us to benefit *instantly* from the work of a large number of people as long
> as they write their applications to rely on the promises POSIX makes.  This
> is crucial for commercial software ("better but nonstandard" just doesn't
> cut it with commercial developers, trust me on this[1]), and helpful even for
> publically-available software (since you don't have to go through it and
> port it to NetBSD).
> 
> "We're almost standard but better in small and annoying ways" is why UNIX
> fragmented to the point where MS-DOS was able to conquer the world.  You
> can always "repair" NetBSD in the privacy of your own machine room, of course;
> just don't be surprised when you start having trouble porting software to it
> because you've "repaired" things that applications writers don't think are
> broken.
> 
> At least System V is effectively dead, and won't be injuring future standards.
> :-)
> 
> [1] Look how far "better but nonstandard" got UNOS...
> 

=========================================================================
Rick Byers                                      Internet Access Worldwide
rickb@iaw.on.ca                                      System Administrator
Welland, Ontario, Canada                                    (905)714-1400
http://www.iaw.on.ca/rickb/                         http://www.iaw.on.ca/