Re: [parted-devel] [PATCH] [RFC] Do not automatically update GPT label in interactive mode
Petr Uzel wrote:
On Wed, Feb 18, 2009 at 08:55:35PM +0100, Jim Meyering wrote:
Petr Uzel petr.u...@suse.cz wrote:
...
+test_expect_success \
+'save a copy of the original primary GPT table' \
+'dd if=$dev of=before count=1 skip=1'
isn't bs=512 missing here ^^^ ?
It's fine to omit it, since bs=512 is the default.
I can confirm that it defaults to 512 on my system. However, I can't
find any reference about default bs value in the dd documentation
(more precisely, it is referenced in BSD and HPUX manpages, but not in
linux).
Thank you for mentioning that.
Here's a proposed patch.
Feedback welcome.
Any language lawyers around? ;-)
From 0c91ae335d45250ed9024ededd36aac40e071d7b Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Thu, 19 Feb 2009 12:35:58 +0100
Subject: [PATCH] doc: dd: document that the default block size is 512 bytes
* src/dd.c (usage): Document the default block size.
* doc/coreutils.texi (dd invocation): Document that the default
block size (bs, ibs, obs) is 512 bytes.
Reported by Petr Uzel.
---
THANKS |1 +
doc/coreutils.texi |2 ++
src/dd.c |6 +++---
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/THANKS b/THANKS
index bedb01a..f2fcd01 100644
--- a/THANKS
+++ b/THANKS
@@ -446,6 +446,7 @@ Peter Moulder rei...@netspace.net.au
Peter O'Gorman bug-coreut...@mlists.thewrittenword.com
Peter Samuelson psamu...@sampo.creighton.edu
Peter Seebach se...@taniemarie.solon.com
+Petr Uzel petr.u...@suse.cz
Petter Reinholdtsen p...@hungry.com
Phelippe Neveu pne...@pcigeomatics.com
Phil Richards phil.richa...@vf.vodafone.co.uk
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 42234d3..8d496ad 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7605,6 +7605,7 @@ dd invocation
@cindex input block size
Set the input block size to @var{bytes}.
This makes @command{dd} read @var{bytes} per block.
+The default is 512 bytes.
@item o...@var{bytes}
@opindex obs
@@ -7612,6 +7613,7 @@ dd invocation
@cindex output block size
Set the output block size to @var{bytes}.
This makes @command{dd} write @var{bytes} per block.
+The default is 512 bytes.
@item b...@var{bytes}
@opindex bs
diff --git a/src/dd.c b/src/dd.c
index 4604ced..6837b7b 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -463,16 +463,16 @@ Usage: %s [OPERAND]...\n\
fputs (_(\
Copy a file, converting and formatting according to the operands.\n\
\n\
- bs=BYTESread and write BYTES bytes at a time\n\
+ bs=BYTESread and write BYTES bytes at a time (also see ibs=,obs=)\n\
cbs=BYTES convert BYTES bytes at a time\n\
conv=CONVS convert the file as per the comma separated symbol list\n\
count=BLOCKScopy only BLOCKS input blocks\n\
- ibs=BYTES read BYTES bytes at a time\n\
+ ibs=BYTES read BYTES bytes at a time (default: 512)\n\
), stdout);
fputs (_(\
if=FILE read from FILE instead of stdin\n\
iflag=FLAGS read as per the comma separated symbol list\n\
- obs=BYTES write BYTES bytes at a time\n\
+ obs=BYTES write BYTES bytes at a time (default: 512)\n\
of=FILE write to FILE instead of stdout\n\
oflag=FLAGS write as per the comma separated symbol list\n\
seek=BLOCKS skip BLOCKS obs-sized blocks at start of output\n\
--
1.6.2.rc1.241.g7bf82
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [parted-devel] [PATCH] [RFC] Do not automatically update GPT label in interactive mode
On Wed, Feb 18, 2009 at 08:55:35PM +0100, Jim Meyering wrote: Petr Uzel petr.u...@suse.cz wrote: ... +test_expect_success \ +'save a copy of the original primary GPT table' \ +'dd if=$dev of=before count=1 skip=1' isn't bs=512 missing here ^^^ ? It's fine to omit it, since bs=512 is the default. I can confirm that it defaults to 512 on my system. However, I can't find any reference about default bs value in the dd documentation (more precisely, it is referenced in BSD and HPUX manpages, but not in linux). -- Best regards / s pozdravem Petr Uzel, Packages maintainer - SUSE LINUX, s.r.o. e-mail: pu...@suse.cz Lihovarská 1060/12 tel: +420 284 028 964 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Timezone handling in date command
Dear guys, I have expierenced the following unexpeted behaviour by using the date command on SuSE SLES10(x86_64): I have timezone setup to Asia/Dubai (GMT+4), which has short name GST (Gulf Standart time) #date Thu Feb 20 20:00:00 GST 2009 #date --utc -d now Thu Feb 20 16:00:00 UTC 2009 - OK UTC+4 #date --utc -d Thu Feb 20 20:00:00 GST 2009 Thu Feb 20 10:00:00 UTC 2009 - ??? UTC+10 I think here some name problems with GST. Because there are four timezones with the same short name GST Guam Standart Time UTC+10 Gulf Standart Time UTC+4 Greenland Standart Time UTC-3 South Georgia Time UTC-2 Here looks like date uses UTC+10 for name GST, which is also timezone GST but Guam Standart time and not Gulf Standart time. How can I force date to use another time offset for GST name? Best regards, Viktor Burba ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Hello
Thx for advise can you please help me as per my question. Rgds Robert On Thu, 2009-02-19 at 05:54 -0700, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Please consider using a more descriptive subject line, so your mail won't be rejected as spam] According to Robert Wamala on 2/19/2009 2:17 AM: Hello can you please help to do with automatic logins with curl You have reached the GNU Coreutils mailing list. The GNU Coreutils are the basic file, shell and text manipulation utilities of the GNU Operating System. You can learn more about GNU Coreutils here: http://www.gnu.org/software/coreutils/ The GNU Coreutils are part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ But you are asking about 'curl'. I am sorry but this is the wrong mailing list. We do not maintain 'curl' here. It is not part of the GNU Coreutils project. We are unable to help you. You may want to try the 'curl' home page for more appropriate resources: http://curl.haxx.se/ - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmdVpoACgkQ84KuGfSFAYBwqwCgkk4IZPuQ55k4gnGmKsbpuMXF iRgAn3Bs7+hYEOofgMrdGkQlyA2J6h5w =HUPm -END PGP SIGNATURE- -- Robert Wamala rob...@rcs-communication.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Hello
On Thu, 19 Feb 2009 16:29:15 +0300 Robert Wamala rob...@rcs-communication.com wrote: Thx for advise can you please help me as per my question. No, we cannot. As Eric stated in the previous email: But you are asking about 'curl'. I am sorry but this is the wrong mailing list. We do not maintain 'curl' here. It is not part of the GNU Coreutils project. We are unable to help you. You may want to try the 'curl' home page for more appropriate resources: http://curl.haxx.se/ Regards, signature.asc Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s documentation misleading
On Thu, Feb 19, 2009 at 08:04:46AM +0100, Jim Meyering wrote: ... Clearly the ls help and manual should instead say: Size of space allocated for each file, in blocks Perhaps with a notice in the manual further explaining potential for difference between the file size and size in blocks? The description in info coreutils ls has more detail: (and is usually referred to by the last paragraph of the man page) `-s' `--size' Print the disk allocation of each file to the left of the file name. This is the amount of disk space used by the file, which is usually a bit more than the file's size, but it can be less if the file has holes. Normally the disk allocation is printed in units of 1024 bytes, but this can be overridden (*note Block size::). For files that are NFS-mounted from an HP-UX system to a BSD system, this option reports sizes that are half the correct values. On HP-UX systems, it reports sizes that are twice the correct values for files that are NFS-mounted from BSD systems. This is due to a flaw in HP-UX; it also affects the HP-UX `ls' program. Thanks for the quick response, that's great the info file is accurate, unfortunately I never looked at it. The source was my next reference after seeing behavior not matching --help and the manual. Surely those should still be corrected, they don't need to contain as much as the info page just something indicating specifically an allocated size. Cheers, Vito Caputo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [md5sum]
Pedro Henrique Marques wrote: But the output shows the verification only from the 3� to last file: To clarify, the problem is that the first and last file were apparently ignored? My md5sum version is 5.2.1 Is this a bug ? The latest version of coreutils is 7.0. I recommend trying a newer version. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We are Microsoft. What you are experiencing is not a problem; it is an undocumented feature. -- Unknown (from fortune's bofh-excuses) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [md5sum]
Matthew Woehlke wrote: Pedro Henrique Marques wrote: But the output shows the verification only from the 3� to last file: To clarify, the problem is that the first and last file were apparently ignored? And second, I think. It would've been helpful to see the exact invocation of md5sum... -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer. GNU Maintainer: wget, screen, teseq http://micah.cowan.name/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -s documentation misleading
vcap...@pengaru.com wrote: The ls -s argument is documented as such: ls --help output: -s, --size print the size of each file, in blocks LS(1) man page: -s, --size print the size of each file, in blocks This leads one to expect some sort of relationship between the size colum in ls -l output, perhaps with rounding to the nearest block, but this is not the case. I know the info is preferred, but would it be okay to simply s/blocks/allocated blocks/? (or used blocks, or something along those lines?) I think it should be possible to make this a bit clearer in a way that has an acceptable impact on the length of --help. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- We are Microsoft. What you are experiencing is not a problem; it is an undocumented feature. -- Unknown (from fortune's bofh-excuses) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
pr and indentation
Original Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/331817 original bug description While the pr command recognizes the --indent (-o) option, page headers are printed without indentation. Expected results (for example, version 5.2.1 from CentOS 4): $ ls /usr/bin | pr --indent 5 | head 2009-02-19 17:43 Page 1 [ 4odb 4rdf 4ss 4ssd Actual results (in 8.04/ pr version 6.10): $ ls /usr/bin | pr --indent 5 | head 2009-02-19 17:45 Page 1 [ 411toppm a2p a2ps a2ps-lpr-wrapper original bug description I have tested with git 'pr', and the same happens: hg...@xango2:/usr/src/buildd/libpst/libpst-0.6.25 $ ls /usr/bin | pr --indent 5 | head 2009-02-19 22:08 Page 1 [ 2to3-2.6 2to3-3.0 404main 411toppm hg...@xango2:/usr/src/buildd/libpst/libpst-0.6.25 $ pr --version pr (GNU coreutils) 7.0.188-0e40e-dirty Although it is not clear what would be the expected behaviour, it seems intuitive that if --indent is provided, all output should be indented. Regards, signature.asc Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
