what are the cases when a prompt would not have been shown? AFAIK, those
cases can be there only because of further options provided by the user, so
it's his fault...
my scripts just does:
cp -d --preserve=mode,timestamps,links --reply=no
and i can't be sure everybody have rsync installed.
My case is the exact opposite of what you are talking about.
Irrespectively of the original files, i want to keep the existing files at
the destination, even if older.
and cp --reply=no, without any other fancy thing that would have avoided a
prompt, was the sweetest thing to do. it was... :(
Yeah, that's exactly the feature I've been wanting (only with mv instead of
cp). I actually joined this list to figure out why it had been deprecated.
One day, when I have time to fully understand the source code, I'll sit down
and write a --no-overwrite patch for mv and cp that silently
alessandro salvatori wrote:
My case is the exact opposite of what you are talking about.
Irrespectively of the original files, i want to keep the existing files at
the destination, even if older.
In that case Eric's suggestion of rsync --ignore-existing is perfect
then.
Bob
except it is not guaranteed to be on a machine
I will go for an horrible:
yes n | cp -i src/ dst/ 21 | grep -v ' overwrite '
Thanks!
-A
On 8/26/07, Bob Proulx [EMAIL PROTECTED] wrote:
alessandro salvatori wrote:
My case is the exact opposite of what you are talking about.
Irrespectively
Mark Rose wrote:
Yeah, that's exactly the feature I've been wanting (only with mv instead of
cp). I actually joined this list to figure out why it had been deprecated.
It was removed because it did not actually prevent overwriting files.
Try this with the old 'mv --reply=no'.
$ touch bar
Eric Blake wrote:
For findutils, I recently added a patch to the import-gnulib.sh script to
call 'find -L -lname '*' -delete' after the fact (yes, this is GNU find
specific, but does the job of deleting all broken symlinks). But it would
be better if gnulib-tool and bootstrap were taught to
I've written a small utility that does easily extract line slices. It has
currently one convenience switch -n, which triggers numbered output.
Sample invocations:
$ linecut --range 1,10:50,80:-200,-1 --number file
$ linecut --range 10,-10 --number file
$ linecut --range 15,15:18,18 --number
Steven Schubiger wrote:
I've written a small utility that does easily extract line slices.
...
I'm here to collect opinions suggestions, so feel free to reject the idea.
Looking at this briefly this looks to be very similar to actions
provided by sed, head and tail. Could you describe
On Sun, Aug 26, 2007 at 09:07:34AM -0600, Bob Proulx wrote:
Looking at this briefly this looks to be very similar to actions
provided by sed, head and tail. Could you describe features in
linecut that are not present there?
An introductory word: linecut was specifically designed with solely
10 matches
Mail list logo
