Thank you for your report. It was most excellently stated and reports such as your are most appreciated. However the behavior you are seeing is expected and used to this effect by other programs. I do not believe it should be changed as it would break programs that depend upon this working like it does and it would leave them without an important capability.
> To reproduce: > > mkdir /tmp/zzz > mknod /tmp/pipe p > cp -dpuxv --parents --backup=numbered /tmp/pipe /tmp/zzz > > /tmp -> /tmp/zzz/tmp > `/tmp/pipe' -> `/tmp/zzz/tmp/pipe' > > <hangs here> At this time your cp command is not hung but rather is trying to copy the contents of the file which is a named pipe. This has blocked waiting for input into the pipe. Other programs can write into that pipe and the output will be copied by the cp command. For an experiment, from another window which this is blocked above try this. echo hello world > /tmp/pipe You should find that the file is now copied and the contents are the output of the echo command which was redirected into the pipe. This behavior is frequently used by randomizing quotation signature generators. I am sure you have seen many of those random quotes at the bottom of people's email messages. Instead of making ~/.signature a file it is made a pipe and programs copy the contents into the mail message. The contents are made to change with each reading of the file/pipe by having another program sit in a loop writing random quotations into it. Silly. But very common. > Oddly, this invocation does work: > > cp -auxv /tmp/pipe /tmp/zzz > `/tmp/pipe' -> `/tmp/zzz/pipe' The -a option is the key. It says to copy all attributes of the file as it sits. This is also called an archive mode. Which is to say symbolic links are recreated and pipes are recreated. It is useful to compare the behavior with pipes to the behavior with symbolic links both with and without the -a option. The -d option only specifies symbolic links and pipes are not symbolic links. You probably want the -a option instead of the -d option. The documentation is a little unclear in this area and could be improved. (I also noticed that the -u option is not documented in the info pages.) The -a option is a GNU extension and one that has proved extremely useful. Since we are discussing cp and pipes we should point out another area of contention. This issue also pops up in relation to the -r option. Traditionally the -r option to copy a tree of files would always copy the contents of the file as in the first case. Which means that if a directory contained a pipe it would block there. However some operating systems modified cp to avoid this when using the -r option because it was not seen as being as useful in that context. Therefore the -r option is somewhat of a portability problem with repect to copying trees if they contain named pipes. Some do one thing and some do others. The standard therefore stated that it was implementation defined behavior. Therefore the -R option was introduced which would have a "new" behavior which would never copy the contents, avoiding blocking on pipes, but would recreate the pipe in the new tree. Portable applications should use the -R option. GNU cp has been in a tug of war and some versions of -r do one thing and others do another. I believe the newest behavior of -r is now identical to the -R option which is probably the most useful and practical implementation. > This is fileutils 4.1 from Redhat rpm fileutils-4.1-10.i386.rpm > running on linux 2.4.18 with low latency patch Hope this helps Bob _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
