On Tue, Nov 06, 2007 at 09:19:49AM -0500, Eric Gorr wrote:
> Kevin Van Vechten wrote:
> > Eric Gorr wrote:
> > > I was just wondering if:
> > >
> > >
> > > 1. 10.4.10 had a bug
> > > 2. 10.5 has a bug
> > > 3. the definition of how the -n option is supposed to work
> has changed
> > >
> > >
> > > It seems strange that cp would return an exit status of 1 now if
> > > the file already exists. After all, the command will do exactly
> > > it is supposed to do and not copy the file.
> > I suppose it was #3. It looks like the exit status was changed due to
> > feedback that returning a zero exit status gives no way to determine
> > whether or not a file was actually copied (<rdar://problem/3624563>).
> > This is a divergence from the FreeBSD behavior in 10.4.10 (FreeBSD
> > introduced the non-standard -n flag). Because -n is non-standard,
> > I'd recommend against using it.
> Ok, thanks.
> Still seems strange that it would be considered an error if the
> command does what it is told to do.
I like the idea of 'cp -n' returning a non-zero status if it
sees an existing file. There are times when you don't want to overwrite
an existing file, but want to know if it was there *during* the cp -
in particular if you're going from a case-sensitive FS to a
case-insensitive FS. While 'cp -i' works fine if humans are driving,
it tends to not work as well if you're doing something automated/scripted.
Whether 'cp -n' should return 0 or non-zero depends on how you
think about what you're asking cp to do. Are you asking it to not perform
the copy for existing files, or to let you know there are existing files
and not overwrite them?
That said, the advice to not use it as its non-standard is probably
the best course.
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden