bug#11809: document "So how do we just simply make a backup file?"
JM> I deliberately restricted the "make backup only" functionality to the JM> very limited case that is documented. Well you had better explicitly document that it does not work with all forms in the cp SYNOPSIS, else people will think it is broken...
bug#11809: document "So how do we just simply make a backup file?"
Jim Meyering wrote:
> jida...@jidanni.org wrote:
>> (info "(coreutils) Backup options") should add some examples, for
>> "So how do we make a backup file of m?"
>> $ ls
>> m
>> $ cp -b m m #no go
>
> Thanks for the suggestion.
> I use this zsh/bash shell function:
>
> backup ()
> {
> local i
> for i in "$@"; do
> command cp -bf "$i" "$i"
> done
> }
>
> but as I inserted the above, I realize it's buggy.
> It doesn't propagate failure like you'd expect,
> so here's a better one:
>
> backup()
> {
> local i fail=0
> for i in "$@"; do
> command cp -bf -- "$i" "$i" || fail=1
> done
> return $fail
> }
>
> That's already almost what info coreutils says:
>
> Make a backup of each file that would otherwise be overwritten or removed.
> As a special case, @command{cp} makes a backup of @var{source} when the
> force
> and backup options are given and @var{source} and @var{dest} are the same
> name for an existing, regular file. One useful application of this
> combination of options is this tiny Bourne shell script:
>
> @example
> #!/bin/sh
> # Usage: backup FILE...
> # Create a @sc{gnu}-style backup of each listed FILE.
> for i; do
> cp --backup --force -- "$i" "$i"
> done
> @end example
>
> I'll adjust that to reflect the above improvement:
> Do you think that's enough?
Here's the doc patch I suggested, but I'll hold off for now.
I'd like to hear if anyone thinks it's worth adding a new option,
which would obviate such a script.
>From 3a1bc89c3e3ca277be49d4fceb60abb57e3fc9d2 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 29 Jun 2012 10:45:31 +0200
Subject: [PATCH] doc: improve sample backup script
* doc/coreutils.texi (cp invocation): Make the backup script exit
with an accurate reflection of any failure.
---
doc/coreutils.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 08ef2d8..5207c44 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7675,9 +7675,11 @@ cp invocation
#!/bin/sh
# Usage: backup FILE...
# Create a @sc{gnu}-style backup of each listed FILE.
+fail=0
for i; do
- cp --backup --force -- "$i" "$i"
+ cp --backup --force -- "$i" "$i" || fail=1
done
+exit $fail
@end example
@item --copy-contents
--
1.7.11.1.59.gbc9e7dd
bug#11809: document "So how do we just simply make a backup file?"
Bernhard Voelker wrote:
> On 06/29/2012 10:48 AM, Jim Meyering wrote:
>> Here's the doc patch I suggested, but I'll hold off for now.
>> I'd like to hear if anyone thinks it's worth adding a new option,
>> which would obviate such a script.
>
> I think it's okay, that special backup case is described in the info
> page of cp twice anyway.
>
>> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
>> index 08ef2d8..5207c44 100644
>> --- a/doc/coreutils.texi
>> +++ b/doc/coreutils.texi
>> @@ -7675,9 +7675,11 @@ cp invocation
>> #!/bin/sh
>> # Usage: backup FILE...
>> # Create a @sc{gnu}-style backup of each listed FILE.
>> +fail=0
>> for i; do
>> - cp --backup --force -- "$i" "$i"
>> + cp --backup --force -- "$i" "$i" || fail=1
>> done
>> +exit $fail
>> @end example
>>
>> @item --copy-contents
>
> When we speak of "backup", then maybe "--preserve=all" would be nice.
>
> BTW: that special backup case accepts -a which includes both -d and -R
> which both are maybe not ideal if you speak about a backup of a regular
> file. The former treats symlinks specially, and the latter is designed
> to recurse into directories - both may be misleading (although -d may
> make some sense in certain situation when creating a backup of a
> symlink). WDYT?
Adding --preserve=all sounds like a good idea.
Thanks.
Allowing this little script to work also for non-regular files
seems like it'd be useful, too. But it's beginning to look as if
this combination of options is both useful and involved enough that
the functionality should be provided by a new --only-backup option.
bug#11816: sort -o: error comes late if opening the outfile fails
If opening the output file for writing is not possible - e.g. because the user doesn't have sufficient privileges, then sort issues an error. The problem is that the whole - then useless - computation is already done. In the following little example, it took ~15s to sort the data, and then to realize that it can't write the result: $ time seq 100 | src/sort --random-sort -o /cantwritehere src/sort: open failed: /cantwritehere: Permission denied real0m14.955s user0m14.936s sys 0m0.042s I'd have expected sort to give the error immediately after startup instead of wasting time for sorting. Shouldn't sort open the outfile right at the beginning (unless in==out), or is this behavior required by some standard? Have a nice day, Berny
bug#11809: document "So how do we just simply make a backup file?"
On 06/29/2012 10:48 AM, Jim Meyering wrote:
> Here's the doc patch I suggested, but I'll hold off for now.
> I'd like to hear if anyone thinks it's worth adding a new option,
> which would obviate such a script.
I think it's okay, that special backup case is described in the info
page of cp twice anyway.
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 08ef2d8..5207c44 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -7675,9 +7675,11 @@ cp invocation
> #!/bin/sh
> # Usage: backup FILE...
> # Create a @sc{gnu}-style backup of each listed FILE.
> +fail=0
> for i; do
> - cp --backup --force -- "$i" "$i"
> + cp --backup --force -- "$i" "$i" || fail=1
> done
> +exit $fail
> @end example
>
> @item --copy-contents
When we speak of "backup", then maybe "--preserve=all" would be nice.
BTW: that special backup case accepts -a which includes both -d and -R
which both are maybe not ideal if you speak about a backup of a regular
file. The former treats symlinks specially, and the latter is designed
to recurse into directories - both may be misleading (although -d may
make some sense in certain situation when creating a backup of a
symlink). WDYT?
Have a nice day,
Berny
bug#11816: sort -o: error comes late if opening the outfile fails
On 06/29/2012 12:54 PM, Bernhard Voelker wrote: > If opening the output file for writing is not possible - e.g. because the user > doesn't have sufficient privileges, then sort issues an error. The problem > is that the whole - then useless - computation is already done. > > In the following little example, it took ~15s to sort the data, > and then to realize that it can't write the result: > > $ time seq 100 | src/sort --random-sort -o /cantwritehere > src/sort: open failed: /cantwritehere: Permission denied > > real0m14.955s > user0m14.936s > sys 0m0.042s > > I'd have expected sort to give the error immediately after startup > instead of wasting time for sorting. > Shouldn't sort open the outfile right at the beginning (unless in==out), > or is this behavior required by some standard? Hmm I think that would be an improvement. Now if there was an issue with sorting (like running out of resources), we'd prefer not to leave the empty output hanging around. Also the in==out case, you'd like to check for write-ability too. Both cases could be handled I think with something like: if (access (outfile, W_OK) != 0 && errno != ENOENT) error (...); cheers, Pádraig.
