Re: Bug#467376: coreutils: Wish there was a version of dd with multiple output files
Russell Coker <[EMAIL PROTECTED]> wrote: > Package: coreutils > Version: 5.97-5.3 > Severity: wishlist > > When setting up test environments (chroots and Xen domains) I often want to > duplicate one block device or large file to several others. > > If I am creating three copies I don't want to read the data three times and > write it three times, I want to read it once and write it three times. That does sound useful. > dd if=source of=dest1 of=dest2 of=dest3 bs=102400k You'd need to use something other than "of=", since the above command has always simply ignored all but the last one. I.e., it's equivalent to this: dd if=source of=dest3 bs=102400k Hmm... but we *could* add an option to make it do what you suggest. > The ideal would be something like the above. But a separate utility as part > of coreutils to perform the same task would be OK. > > Ideally such a program would use asynchronous IO or threads to allow all > writes to be performed at the same time (when writing to a RAID array three > writes theoretically can potentially be completed in the same amount of time > as one write). Would you like to write the patch? :-) Or even just add it to the TODO list? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Fix test failure where rm would appear to succeed incorrectly.
I have been seeing the rm fail-eperm test sporadically fail. It turns
out that there is a race. The test is opportunistically looking for
files that it can't remove so as to provide a test for that part of
rm's functionality. But between the time it finds a candidate file
and the time it tries to test rm on the file that file may have
already been removed external to the test script. The code didn't
expect that and therefore threw an error message. This suggested
patch fixes the problem by detecting that case and ignoring it.
Please fetch this patch.
git fetch --no-tags git://git.proulx.com/idutils
rm-fail-eperm-fix:rm-fail-eperm-fix
Bob
2008-02-25 Bob Proulx <[EMAIL PROTECTED]>
Fix test failure where rm would appear to succeed incorrectly.
* tests/rm/fail-eperm: Ignore files that were opportunistically chosen
to test permission failures but disappear before we can finish the test.
diff --git a/tests/rm/fail-eperm b/tests/rm/fail-eperm
index 5fa54b0..e9e2108 100755
--- a/tests/rm/fail-eperm
+++ b/tests/rm/fail-eperm
@@ -96,6 +96,17 @@ foreach my $dir (@dir_list)
close RM;
my $rc = $?;
+ # This test opportunistically looks for files that can't
+ # be removed but those files may already have been removed
+ # by their owners by the time we get to them. It is a
+ # race condition. If so then the rm is successful and our
+ # test is thwarted. Detect this case and ignore.
+ if ($rc == 0)
+ {
+ next if ! -e $target_file;
+ die "$ME: unexpected exit status from `$cmd';\n"
+ . " got 0, expected 1\n";
+ }
if (0x80 < $rc)
{
my $status = $rc >> 8;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
Jim Meyering wrote: > Russell Coker <[EMAIL PROTECTED]> wrote: >> If I have a file that is 2G in size but wish to discard the last 1G of data >> then there seems to be no program available to do this. >> >> I think it would be ideal to have a program as part of coreutils that allows >> you to resize a file. If the new length is longer than the old length then >> it would either write zeros to the end or extend the file (with a hole) >> via the truncate() system call according to the wish of the user. If the new >> length is shorter then it would just call truncate(). >> >> I would be happy to contribute the code for this. This will require some >> discussion with upstream, but it seemed best to start the discussion here. > > That would be nice. > > If the mythical miscutils project were more concrete, > I'd say this tool belongs there. I'm planning to push code to this very "project" very soon. As previously discussed I'm going to push this to the misc-utils directory of the util-linux-ng project. We can split that directory as a new project in future if ever deemed necessary. > I'm not 100% sure it should be written in C, especially > since I wrote it in Perl: And here's a shell version: http://www.pixelbeat.org/scripts/truncate I'm probably going to (re)write all "miscutils" in C though. > Russell, if you want to write a C version and do the usual > complete job (update coreutils.texi, NEWS, etc. and add tests), > I'd probably go for it. The only reason not to would be if > miscutils is now viable, and even then... > One advantage of using C/coreutils/gnulib > is that you'd get k, M, G, ... byte-count suffixes for free. Note I already got util-linux-ng using the "coreutils" suffixes, so this should be a good fit. Russell if you want to push code to me it's fine, but I was going to work on this tool anyway. thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
Russell Coker <[EMAIL PROTECTED]> wrote: > On Monday 25 February 2008 21:29, Pádraig Brady <[EMAIL PROTECTED]> wrote: >> Russell if you want to push code to me it's fine, >> but I was going to work on this tool anyway. > > I don't have any code (yet). If you are going to work on it then I would be > more than happy to leave it to you. I would be very interested in testing > it, but my coding time is unfortunately quite limited at the moment and I'd > prefer to focus on the things that don't have someone else about to work on > them. > > One non-obvious feature request that I have is for a truncate on a > non-existant file to create it (similar to the way "touch" is commonly used > to create files). The obvious question is then "Why?" ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: argve0, psfool
Andreas Schwab wrote:
> Andreas Schwab <[EMAIL PROTECTED]> writes:
>
>> Brian Dessent <[EMAIL PROTECTED]> writes:
>>
>>> "Daniel C. Bastos" wrote:
>>>
I always miss these two programs on every system I meet. argv0 is very
handy when dealing with programs that care about argv[0] and psfool is
essential when giving out passwords through the command line. I figure
these two should be in coreutils.
>>> perl -e 'exec { "real" } "fake", "arg1", "arg2"'
>> bash -c 'exec -a "$0" "$@"' real fake arg1 arg2
>
> That should of course be:
>
> bash -c 'exec -a "$0" "$@"' fake real arg1 arg2
I think that should be?
bash -c 'exec -a "$@"' fake real arg1 arg2
Anyway, why would one use an argve0 tool rather than use a symlink?
A real example would be great.
thanks,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: argve0, psfool
Pádraig Brady <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> That should of course be: >> >> bash -c 'exec -a "$0" "$@"' fake real arg1 arg2 > > I think that should be? > > bash -c 'exec -a "$@"' fake real arg1 arg2 No, $0 expands to fake and "$*" expands to "real arg1 arg2". Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
Russell Coker <[EMAIL PROTECTED]> wrote: > On Monday 25 February 2008 22:11, Jim Meyering <[EMAIL PROTECTED]> wrote: >> > One non-obvious feature request that I have is for a truncate on a >> > non-existant file to create it (similar to the way "touch" is commonly >> > used to create files). >> >> The obvious question is then "Why?" > > One specific case is where I want a large sparse file to exist - which may > have been created previously. So "truncate 2g /var/spool/whatever/foo" would > make that file exist and be 2g in size regardless of whether it was there > before. If you don't mind truncating first, how about this? true > /var/spool/whatever/foo dd bs=1 seek=2G of=/var/spool/whatever/foo < /dev/null ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fix test failure where rm would appear to succeed incorrectly.
[EMAIL PROTECTED] (Bob Proulx) wrote: > I have been seeing the rm fail-eperm test sporadically fail. It turns > out that there is a race. The test is opportunistically looking for > files that it can't remove so as to provide a test for that part of > rm's functionality. But between the time it finds a candidate file > and the time it tries to test rm on the file that file may have > already been removed external to the test script. The code didn't > expect that and therefore threw an error message. This suggested > patch fixes the problem by detecting that case and ignoring it. > > Please fetch this patch. > > git fetch --no-tags git://git.proulx.com/idutils > rm-fail-eperm-fix:rm-fail-eperm-fix > > 2008-02-25 Bob Proulx <[EMAIL PROTECTED]> > > Fix test failure where rm would appear to succeed incorrectly. > * tests/rm/fail-eperm: Ignore files that were opportunistically chosen > to test permission failures but disappear before we can finish the test. Thanks for tracking that down and fixing it. I applied your patch. (though, fyi, the fetch failed) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Fix test failure where rm would appear to succeed incorrectly.
Jim Meyering wrote: > Bob Proulx wrote: > > git fetch --no-tags git://git.proulx.com/idutils > > rm-fail-eperm-fix:rm-fail-eperm-fix > > Thanks for tracking that down and fixing it. > I applied your patch. (though, fyi, the fetch failed) I crossed the streams! That should have been: s/idutils/coreutils/ My bad. I should have double checked it before I sent it. Thanks for dealing with it anyway. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
Jim Meyering <[EMAIL PROTECTED]> writes: > If you don't mind truncating first, how about this? > > true > /var/spool/whatever/foo > dd bs=1 seek=2G of=/var/spool/whatever/foo < /dev/null Also, the latter command works even if the former command is omitted. That is, by itself, that invocation of dd resizes /var/spool/whatever/foo to 2 GiB, discarding or extending the file as needed, which is what the original request asked for. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
On Monday 25 February 2008 21:29, Pádraig Brady <[EMAIL PROTECTED]> wrote: > Russell if you want to push code to me it's fine, > but I was going to work on this tool anyway. I don't have any code (yet). If you are going to work on it then I would be more than happy to leave it to you. I would be very interested in testing it, but my coding time is unfortunately quite limited at the moment and I'd prefer to focus on the things that don't have someone else about to work on them. One non-obvious feature request that I have is for a truncate on a non-existant file to create it (similar to the way "touch" is commonly used to create files). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
On Monday 25 February 2008 22:11, Jim Meyering <[EMAIL PROTECTED]> wrote: > > One non-obvious feature request that I have is for a truncate on a > > non-existant file to create it (similar to the way "touch" is commonly > > used to create files). > > The obvious question is then "Why?" One specific case is where I want a large sparse file to exist - which may have been created previously. So "truncate 2g /var/spool/whatever/foo" would make that file exist and be 2g in size regardless of whether it was there before. Of course writing shell code to check for the existence of a file is not difficult, but the people who wrote touch(1) seemed to think this is a good idea. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#467378: coreutils: Please include a program to truncate files
On Tuesday 26 February 2008 10:08, Paul Eggert <[EMAIL PROTECTED]> wrote: > > dd bs=1 seek=2G of=/var/spool/whatever/foo < /dev/null > > Also, the latter command works even if the former command is omitted. > That is, by itself, that invocation of dd resizes > /var/spool/whatever/foo to 2 GiB, discarding or extending the file as > needed, which is what the original request asked for. Yes, that does it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
