bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp command interactive mode priority


From: Bob Proulx
Subject: Re: cp command interactive mode priority
Date: Sat, 16 Jul 2005 10:46:06 -0600
User-agent: Mutt/1.5.9i

> I have been surprised by the way 'cp' handles the '-i' (interactive) mode.

I could see that the behavior is confusing.  Especially because it is
different from the way 'rm' handles those options.  But 'rm' and 'cp'
are different commands.

When things have been a certain way for long enough they become the
standard behavior.  The UNIX commands have been the way that they are
for many years.  People expect certain core behavior.  Changing it
causes much consternation.

With 'rm' the two options -i and -f each cancel the other one out.
The last option specified takes affect.  But with 'cp' the options are
not opposites at all.  With 'cp' the two options do completely
different things.

The standard behavior for cp is documented here:

  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html

Here is what the standard says about this:

  If dest_file exists, the following steps shall be taken:

   1. If the -i option is in effect, the cp utility shall write a
      prompt to the standard error and read a line from the standard
      input. If the response is not affirmative, cp shall do nothing
      more with source_file and go on to any remaining files.

Okay, simple enough.  If there is a -i option then ask.

   2. A file descriptor for dest_file shall be obtained by performing
      actions equivalent to the open() function defined in the System
      Interfaces volume of IEEE Std 1003.1-2001 called using dest_file
      as the path argument, and the bitwise-inclusive OR of O_WRONLY
      and O_TRUNC as the oflag argument.

If there was a -i option then ask.  We are here if there was no -i
option or the user said yes to a query.  Once here the destination
file is opened for writing.

   3. If the attempt to obtain a file descriptor fails and the -f
      option is in effect, cp shall attempt to remove the file by
      performing actions equivalent to the unlink() function defined
      in the System Interfaces volume of IEEE Std 1003.1-2001 called
      using dest_file as the path argument. If this attempt succeeds,
      cp shall continue with step 3b.

The -f option comes into play here.  The -f option says that if the
open failed then to try to remove the destination file.  This is
regardless of the presence of the -i option.  If there was a -i option
then ask.  We are here if there was no -i option or the user said yes
to a query and the destination file was not able to be opened for
writing.

> I expected the '-i' to be low priority. I mean that if we would add '-f' to 
> force the copy, this would override the '-i' option.

The two options are not related to each other.  Because of legacy
expectations and standardization of the command they cannot be changed
to be related to each other.

> Also, I think that putting -i by default would be good, but this is a plus.

No.  That would break zillions of scripts and programs.  The -i option
may be useful for an interactive shell alias.  But it is a personal
preference to be customized in the personal environment.  It is not
something to make as a global change to the command.

> People are well aware that copying a file on another normally generates an 
> error.

No.  That is incorrect.  Copying a file over another file does not
normally generate an error.

> If they expect this error to happen, then they will just add a '-f' and no 
> questions anymore.

But the -f option to cp does not turn off prompting.

> Now I am having problems using this command. I could use the default RHEL 4 
> alias which is 'cp -i', but then we cannot add anymore the -f command to 
> force copying.
> 
> Thus, putting the '-f' command to override the '-i' would be extremely 
> useful. Alos, if somebody has defined this '-f', then it means that he 
> really wanted to overwrite existing files.
> This means that we would be able to put a command like 'cp -i -f ... ...' 
> and this would copy the files and overwrite the existing files without any 
> notice.

It would be possible to create a new long option to create the
behavior you desire and add it to GNU cp as an extension.  Such
options have been discussed in coreutils before and some discussion
has happened quite recently.  But so far no one has had the time to
create the code to do this.

> I hope this could be done. I'm sure this will help make things simpler for 
> lot of people. You can have a look at google with 'cp overwrite'. E.g.:
> http://groups.google.ch/group/comp.os.linux.misc/browse_thread/thread/6f4d8a13c0247ec3/f510ccaaacf655b0?q=cp+overwrite&rnum=25&hl=fr#f510ccaaacf655b0
> 
> Everybody thinks that this is a bug. Me also..

Everybody is wrong.  :-) (chuckle) Seriously that thread was from
several years ago and only one person from there thought it was a bug.
I don't think it is possible to append to that thread now.  But
hopefully users searching for this discussion will also find this one
too.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]