[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cp hangs when copying pipes
From: |
Bob Proulx |
Subject: |
Re: cp hangs when copying pipes |
Date: |
Wed, 3 Apr 2002 23:06:28 -0700 |
> I agree that reading a pipe or socket should block until someone writes it.
> What I need is a way to tell cp to not read them but just copy them
> without having to give it the -R option, since I don't want recursion.
Hmm... Yes, that would be useful!
> What do you think about -p forcing this behavior? Or adding another flag
> (or flags if you want to seperate pipes from sockets) such as
> --dont-read-pipes --dont-read-sockets ?
There are already too many options already. Perhaps this would be
most appropriate with the --preserve functionalty. Perhaps
--preserve=pipes or something similar.
cp --preserve=links,pipes foo bar
Or shouldn't 'all' preserve pipes?
cp --preserve=all foo bar
> Or +R to reverse the effects of -R (because -a is -dpR) so I could
> do cp -a +R ?
Options starting with a + were previously used for long options such
as +recursive but for various reasons that many are not happy with
that was changed to the more standard compliant behavior of long
options starting with a double dash as in --recursive. Once burned
and twice shy there. I don't remember the full reasons but I would
avoid options starting with a +.
> Or a number to specify the depth of recursion so I could use 1?
>
> What I do now is run `find . ! -type d ! -type s ! -type p -maxdepth
> 1' to generate the list of files for cp to examine which seems hacky
> (not to mention slow).
Not to distract from the discussion of preserving pipes as pipes, how
about the following? I would think this would be faster. Although it
does have ARG_MAX limitations.
for f in *; do test -f $f && echo $f; done
Bob