Re: ls -l|head seems to look at all files in directory
* Reuben Thomas (r...@sc3d.org) wrote: On Mon, 25 May 2009, Jim Meyering wrote: To do what he wants you have to know that ls -1U is the only way to get one output entry per readdir call. Reuben, you want to do it like this: ls -1U|head|xargs ls -l Thanks for the hint about -1, but this doesn't seem to make any difference: I run ls -1U|head in a directory with lots of files (about 10,000) and it pauses for a minute or so before giving me my ten lines of output. If I run the command again, then of course it runs almost instantly, so I'm not sure what use the loops are in the tests you give. Are all the files just normal files - or are any symlinks to other directories or mount points? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date overflow in year 2038
* James Youngman (j...@gnu.org) wrote: On Sat, Feb 14, 2009 at 3:45 AM, David M. Dowdle ddow...@clouded.leopard.net wrote: I'd rank this as low priority, but people doing things like 30 year mortages will be hitting this already. Mortgage calculations probably shouldn't be using time_t anyway; use of time_t for future calculations assumes that we already know how long each year is going to be, to the nearest second[1].Mortgage agreements on the other hand specify dates in civil time and therefore the duration of the agreement in seconds can't be precisely known when the agreement is signed. snip [1] ... or that the precise alignment between future values of time_t and calendar time doesn't matter much Well indeed; I reckon a difference of 1 second over a 25 year mortgage on a million $ mortgage (at 5%) would be about 13c difference in the amount of interest - and that assumes you weren't paying any capital back, so I'm not sure it's that important (especially if they were careful in how they worded the agreement). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date overflow in year 2038
* Eric Blake (e...@byu.net) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to David M. Dowdle on 2/13/2009 8:45 PM: clouded:~ date -d Fri Jan 19 03:14:08 UTC 2038 +%s date: invalid date `Fri Jan 19 03:14:08 UTC 2038' clouded:~ 03:14:07 is apparently when 32bit time_t hits MAXINT Yep, and that's why many newer systems are switching to 64-bit time_t. But changing the size of size_t is an ABI difference, so not one that you can easily port to older kernels. I'd rank this as low priority, but people doing things like 30 year mortages will be hitting this already. Not a bug in coreutils, but an inherent limitation in your kernel. Just like the old limitation that you couldn't have a file larger than 2GB until you upgraded to a kernel with 64-bit off_t support. Erm really? Sure the kernel might keep the date in 32bit but he wasn't trying to read or set system time - so the kernels view of time is mostly irrelevant. I'm guessing coreutils uses a lot of libc for it, and I suspect that is where there maybe the limitation. (I've seen some systems that really get upset if their time is set to after 2038 - so please be careful if you are trying that). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Threaded versions of cp, mv, ls for high latency / parallel filesystems?
* Andrew McGill ([EMAIL PROTECTED]) wrote: Greetings coreutils folks, There are a number of interesting filesystems (glusterfs, lustre? ... NFS) which could benefit from userspace utilities doing certain operatings in parallel. (I have a very slow glusterfs installation that makes me think that some things can be done better.) For example, copying a number of files is currently done in series ... cp a b c d e f g h dest/ but, on certain filesystems, it would be roughly twice as efficient if implemented in two parallel threads, something like: cp a c e g dest/ cp b d f h dest/ since the source and destination files can be stored on multiple physical volumes. Of course you can't do that by hand since each might be a directory with an unbalanced number of files etc - so you are right, something smarter is needed (my pet hate is 'tar' or 'cp' working it's way through a source tree of thousands of small files). Simlarly, ls -l . will readdir(), and then stat() each file in the directory. On a filesystem with high latency, it would be faster to issue the stat() calls asynchronously, and in parallel, and then collect the results for display. (This could improve performance for NFS, in proportion to the latency and the number of threads.) I think, as you are suggesting, you have to end up doing threading in the userland code which to me seems to be mad since the code doesn't really know how wide to go and it's a fair overhead. In addition this behaviour can be really bad if you get it wrong - for example if 'dest' is a single disc then having multiple writers writing two large files leads to fragmentation on many filesystems. I once tried to write a backup system that streamed data from 10's of machines trying to write a few MB at a time on Linux, each machine being a separate process; unfortuantely the kernel was too smart and ended up writing a few KB from each process before moving onto the next leading to *awful* throughput. Question: Is there already a set of improved utilities that implement this kind of technique? If not, would this kind of performance enhancements be considered useful? (It would mean introducing threading into programs which are currently single-threaded.) One could also optimise the text utilities like cat by doing the open() and stat() operations in parallel and in the background -- userspace read-ahead caching. All of the utilities which process mutliple files could get small speed boosts from this -- rm, cat, chown, chmod ... even tail, head, wc -- but probably only on network filesystems. I keep wondering if the OS level needs a better interface; an 'openv' or 'statv' or I'm currently wondering if a combined call would work - something which would stat a path, if it's a normal file, open it, read upto a buffers worth and if finished close it - it might work nicely for small files. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort seems deficient
* Jim Meyering ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: ??? I just used sort on a redhat Enterprise 5 server. ??? Sort seems to ignore leading . characters.? This is incorrect. How sort works depends on your locale. This link explains and tells you how to change that behavior: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 That explanation is somewhat unclear whether it's due to an unexpected behaviour of the locale or the locale tables actually being broken. I tried to read bits of the Unicode spec last time I hit this and came away not being entirely sure whether it was actually valid behaviour. If someone could point to something which says 'you should sort these non-alphanumeric characters like this' and the Linux one doesn't then perhaps someone will fix it. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Coreutils binary sizes over time
* Alfred M. Szmidt ([EMAIL PROTECTED]) wrote: Would be interesting to see how normal hard drive sizes have grown in that time as well. Of course hard drive growth is fast; but not everything is as fast; e.g. seek time and memory latency. But these graphs, while quite fun to watch, do not really provide much information, gcc's output has changed alot over the years, and the goal isn't to compile small binaries, but semi-fast ones, and that will always lead to bloat (what functions get inlined, how gcc compiles the same functions across versions, ...) Indeed; still it seems wise to keep an eye on sizes just to make sure things aren't getting silly. Even things how the binary format has changed is something that one has to take into account, 10 years ago is a.out times, which had much smaller binaries than ELF. Nod; these are all ELF. What is the drop at 9 epoch? That one looks fun; I am guessing it is the move to glibc 2.x? Yes, it appears to be - the first one is linked against libc.so.5 and an earlier dynamic linker I don't have. Going back to /bin/ls for a minute; using /usr/bin/time -a on /bin/ls /etc the number of minor page faults isn't actually as simple a story as the sizes: fu 3.16-5.3 253 fu 4.0258 fu 4.1-10 289 cu 5.2.1-2 370 cu 5.97-5 400 cu 6.10-2 313 cu 6.10-2007 315 (Those correspond to the points on the graph, except the first one is missing since it is the libc 1.x version I can't easily run). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Coreutils binary sizes over time
Hi, Out of a bit of boredom (and avoiding trying to fix a VHDL problem) I decided to graph the sizes of a few of the binaries from coreutils, as packaged by debian over time (I've included fileutils/shellutils). At: http://www.treblig.org/pics/debianbinarysizes.png you can see a graph showing ls, du, df, true, and chmod over about 10 years. The raw data is here: http://www.treblig.org/data/debiansizes.csv All of these are the Linux/x86 binary packages and all binaries are ELF, stripped, with shared libs. I've not made much attempt to analyse why things are growing; although the fun one is the size of 'true' that used to be a tiny shell script. It's a bit scary that 'true' has gone from a 395 byte script to a 22k binary in 10 years (even the first binary version I have is under 5k); I can imagine that some of the other binaries probably have more to do with system interaction (e.g. ls gaining selinux support). Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [CRM114spam]: bug in printf bash command
* J?rgen Niinre ([EMAIL PROTECTED]) wrote: Hello coreutils maintainer, The bug is with the command printf: [EMAIL PROTECTED] %02i 09 -bash: printf: 09: invalid number [EMAIL PROTECTED] Not-a-bug Numbers starting with a '0' are interpreted as Octal like in C; e.g. printf %02i 011 gets you 09. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d and the leapsecond
* Paul Eggert ([EMAIL PROTECTED]) wrote: Dr. David Alan Gilbert [EMAIL PROTECTED] writes: Now as I understand it the Unix time can't represent the leapsecond in the seconds-since-epoch, but if that is a valid UTC date then should it really accept it as input ? Yes, on hosts that support leap seconds. On hosts that don't one could argue either way, but at least the behavior should be documented. Are you sure that whatever change made date stop taking the 60 only stopped it on hosts that don't support leap second? The other point you mentioned I think has already been addressed in CVS coreutils. Thanks for mentioning the problems. I installed this patch. Thanks. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem with split
* John Joseph Bachir ([EMAIL PROTECTED]) wrote: it seems that on os x, split can only make files as big as 600 megs or so. here is the command i am using: split -b4700m myFile.tar.gz myFile.tar.gz_ ; Which should be about DVD sized chunks. But the files come out a little over 600 megs each. I'd bet the problem here is the representation of '4700m'; I'm guessing the largest value is 2^32 (4 294 967 296) That would be the same as -b 4096m I think, so I think it has wrapped around and you have 4700-4096=~604M files? I suspect if you split at 2300m you should get something sensible and put two on a disc. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date -d and the leapsecond
Hi, I've noticed that there is a change in behaviour where in recent CVS, date -d will not accept a second count of 60 - i.e. date -d Sat Dec 31 23:59:60 UTC 2005 gives 'invalid date' - where as the older 5.2.1 accepts it (and gives midnight Jan 1). Now as I understand it the Unix time can't represent the leapsecond in the seconds-since-epoch, but if that is a valid UTC date then should it really accept it as input ? There also appears to be an inconsistency in the documentation; in the info page '27.3 Time of day items' it states: SECOND is a number between 0 and 59 In the --help output of date it says: %S second (00..60); the 60 is necessary to accommodate a leap second (Does date ever generate a value of 60 seconds on non-Unix systems?) Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
The output of ptx
Hi, I could do with a hand understanding the output of ptx. As input I'm using the two line piece of text: The penguins like to eat fish at each meal. Fish must be fresh and of a variety of species to add some interest to their meal. If I use the command: ptx -S\n file (The full output is later on for those trying to see context) then the first line of output is: like to eat fish at each meal. Fish must be fresh and/penguins I'm trying to understand why '/penguins' is on the end of that; it appears to be the word that would actually go to the left of the left piece of text. Similarly further down I have: meal. Fish must be/ The penguins like to eat fish at each And the 'meal. Fish must be/' seems to be the text that would go to the right of the rightmost text. To me it looks like the rule is something like there are 4 pieces of output on each line: a b c d Where b is the text just before the keyword, c is the keyword followed by some text a is some text that was after 'c' if there is some spare space on the left. d is some text that would have been before 'b' if there is some spare space on the right. This seems confusing - has anyone got a better explanation? As a by-the-way, the info docs suggest that there is a default ignore list that should be in '/usr/local/lib/eign'; this doesn't seem to exist in the coreutils package at all, but I've found a file hanging around an installation of groff (in /usr/share/groff/1.18.1/eign on my installation). Thanks, Dave Full output: like to eat fish at each meal. Fish must be fresh and /penguins each meal. Fish must be/ The penguins like to eat fish at interest to their meal.of a variety of species to add some of a variety of species to add some interest to their meal. each meal. Fish must be fresh and /eat fish at The penguins like to eat fish at each meal. Fish must be fresh/ fish at each meal. Fish must be fresh and/like to eat /penguins like to eat fish at each meal. Fish must be fresh and be/ The penguins like to eat fish at each meal. Fish must The penguins like to eat fish at each meal. Fish must be/ at each meal. Fish must be fresh and /to eat fish variety of species to add some interest to their meal. of a Fish must be/The penguins like to eat fish at each meal. /like to eat fish at each meal. Fish must be fresh and to add some interest to their meal./of species to eat fish at each meal. Fish must be fresh and /like some interest to their meal/of a variety of species to add their meal. of a variety of species to add some interest to meal. Fish must be/ The penguins like to eat fish at each of a variety of species to add some interest to their meal. their meal. of a variety of species to add some interest to species to add some interest to their meal. /variety of must be/The penguins like to eat fish at each meal. Fish . of a variety of species to add some interest to their meal of species to add some interest to their meal./a variety interest to their meal. of a variety of species to add some -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
* Jim Meyering ([EMAIL PROTECTED]) wrote: $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory The 'mv' is straight out of recent cvs. I'm in an ext3 filesystem on Linux (Ubuntu). Am I misunderstanding something about that warning or is this a bug? It depends on the semantics of the rename syscall. And those semantics vary from system to system. On older linux systems (probably 2.4.x, certainly 2.2.20, which I've just tested) your mv command renames `a' to b/sym. OK, as far as I can tell on the 2.6.x machines I've tried it on it doesn't. Losing systems probably deserve a configure-time test and a rename wrapper to correct for the unexpected behavior. Nod. Perhaps the warning needs a warning that it can't be relied on? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv trailing slash warning
Hi, In the info pages for 'mv' is the following statement: --- _Warning_: If you try to move a symlink that points to a directory, and you specify the symlink with a trailing slash, then `mv' doesn't move the symlink but instead moves the directory referenced by the symlink. *Note Trailing slashes::. --- Hmm ok - so I try: $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory The 'mv' is straight out of recent cvs. I'm in an ext3 filesystem on Linux (Ubuntu). Am I misunderstanding something about that warning or is this a bug? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
./expr 6 + -2 = 8
Hi, From the current cvs (as of a few minutes ago) when I do ./expr 6 + -2 I get 8. Every other version of expr I've tried gets 4 which really does seem right. (This is on ubuntu Linux gcc 3.3.5 on x86) Can anyone replicate this? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
Hi,
Here is my current set of diffs (10 sets of examples) against
latest CVS.
Please examine and apply.
Dave
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
Index: ChangeLog
===
RCS file: /cvsroot/coreutils/coreutils/ChangeLog,v
retrieving revision 1.1287
diff -u -r1.1287 ChangeLog
--- ChangeLog 6 May 2005 17:57:59 - 1.1287
+++ ChangeLog 8 May 2005 17:58:56 -
@@ -1,3 +1,8 @@
+2005-05-07 Dave Gilbert [EMAIL PROTECTED]
+
+ * chmod.c, chroot.c, cksum.c, comm.c, cp.c, csplit.c,
+ cut.c, date.c, dd.c, df.c: Add examples
+
2005-05-06 Paul Eggert [EMAIL PROTECTED]
* Version 5.3.1.
Index: src/chmod.c
===
RCS file: /cvsroot/coreutils/coreutils/src/chmod.c,v
retrieving revision 1.110
diff -u -r1.110 chmod.c
--- src/chmod.c 4 May 2005 17:22:25 - 1.110
+++ src/chmod.c 8 May 2005 17:58:57 -
@@ -350,6 +350,16 @@
\n\
Each MODE is of the form `[ugoa]*([-+=]([rwxXst]*|[ugo]))+'.\n\
), stdout);
+ printf (_(\
+\n\
+Examples:\n\
+ %s +x afile Make 'afile' executable.\n\
+ %s g+r afileMake 'afile' readable by members of its group.\n\
+ %s o-r afileRemove read access for everyone outside the group.\n\
+ %s 600 afileMake 'afile' readable and writeable by the owner only.\n\
+ %s -R a+w adir Directory 'adir' all children made writeable by all.\n\
+),
+program_name, program_name, program_name, program_name, program_name);
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
exit (status);
Index: src/chroot.c
===
RCS file: /cvsroot/coreutils/coreutils/src/chroot.c,v
retrieving revision 1.48
diff -u -r1.48 chroot.c
--- src/chroot.c17 Nov 2004 00:56:25 - 1.48
+++ src/chroot.c8 May 2005 17:58:57 -
@@ -57,6 +57,14 @@
\n\
If no command is given, run ``${SHELL} -i'' (default: /bin/sh).\n\
), stdout);
+ printf (_(\
+\n\
+Examples:\n\
+ %s /mnt/newStart a new shell with '/mnt/new' as its root.\n\
+ %s /mnt/new bin/prog Run 'bin/prog' with '/mnt/new' as its root.\n\
+),
+program_name, program_name);
+
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
exit (status);
Index: src/cksum.c
===
RCS file: /cvsroot/coreutils/coreutils/src/cksum.c,v
retrieving revision 1.74
diff -u -r1.74 cksum.c
--- src/cksum.c 6 Mar 2005 16:30:57 - 1.74
+++ src/cksum.c 8 May 2005 17:58:57 -
@@ -277,6 +277,14 @@
), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ printf (_(\
+\n\
+Examples:\n\
+ %s afile Print CRC checksum and byte count for 'afile'.\n\
+ %s afile bfile Print separate checksums and byte counts for each file.\n\
+),
+ program_name, program_name);
+
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
exit (status);
Index: src/comm.c
===
RCS file: /cvsroot/coreutils/coreutils/src/comm.c,v
retrieving revision 1.81
diff -u -r1.81 comm.c
--- src/comm.c 12 Apr 2005 06:46:10 - 1.81
+++ src/comm.c 8 May 2005 17:58:57 -
@@ -92,6 +92,14 @@
), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ printf (_(\
+\n\
+Examples:\n\
+ %s file1 file2Compare presorted files; display unique and common
lines.\n\
+ %s -1 -2 f1 f2List lines common to both files.\n\
+ %s -3 f1 f2 List lines unique to either file.\n\
+),
+ program_name, program_name, program_name);
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
exit (status);
Index: src/cp.c
===
RCS file: /cvsroot/coreutils/coreutils/src/cp.c,v
retrieving revision 1.206
diff -u -r1.206 cp.c
--- src/cp.c28 Mar 2005 17:49:12 - 1.206
+++ src/cp.c8 May 2005 17:58:58 -
@@ -253,6 +253,16 @@
options are given and SOURCE and DEST are the same name for an existing,\n\
regular file.\n\
), stdout);
+ printf (_(\
+\n\
+Examples:\n\
+ %s a nMake a copy of 'a' with the name 'n'.\n\
+ %s a dCopy 'a' as a new file 'a' in the existing directory 'd'.\n\
+ %s -a d1 d2 Copy directory 'd1' and its children into 'd2/d1'.\n\
+ %s -ax d1 d2 As above but make sure to stay in the same filesystem.\n\
+),
+ program_name, program_name, program_name, program_name);
+
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
exit (status
Re: [Patch] Adding examples to the man pages
* Dave Gilbert (Home) ([EMAIL PROTECTED]) wrote: Then let's do the latter, as it's simpler to use the same rule everywhere. I changed the patch to do that, and installed it. Here's the new output of cat --help: Unfortunately I haven't had time this weekend to look at it (except look at your changes); that are OK - although as you see my preference is for a bit more descriptive text - but that is just personal preference. It is quite interesting that the combination of the use of help2man and the insertion of the command string rather than hard coding 'cat' for example means that it is not possible to do multiple line descriptions, since help2man requires that subsequent lines in a multiline description line up in the columns. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
* Jim Meyering ([EMAIL PROTECTED]) wrote: Thanks for persevering. Please base your changes on what is in CVS. Here are instructions for checking out the latest: http://savannah.gnu.org/cvs/?group=coreutils OK, here is a handful of stuff against the CVS checkout. Is this OK? Dave P.S. Which type of copyright thing do I need for this? If someone can point me at the relevant stuff I'll try and get it sorted. -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ diff -ur ../../orig/coreutils-cvs/src/basename.c src/basename.c --- ../../orig/coreutils-cvs/src/basename.c 2004-11-17 00:56:25.0 + +++ src/basename.c 2005-04-03 16:32:28.0 +0100 @@ -64,6 +64,15 @@ ), stdout); fputs (HELP_OPTION_DESCRIPTION, stdout); fputs (VERSION_OPTION_DESCRIPTION, stdout); + fputs (_(\ +Examples:\n\ + basename /usr/foo/lossage/functions.l returns functions.l\n\ + basename /usr/foo/lossage/functions.l .l returns functions\n\ + basename functions.lisp p returns functions.lis\n\ + basename functions.foo .bar returns functions.foo\n\ +\n\ +), stdout); + printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT); } exit (status); diff -ur ../../orig/coreutils-cvs/src/cat.c src/cat.c --- ../../orig/coreutils-cvs/src/cat.c 2004-09-21 23:26:42.0 +0100 +++ src/cat.c 2005-04-03 18:00:19.0 +0100 @@ -118,6 +118,15 @@ -B, --binary use binary writes to the console device.\n\n\ ), stdout); #endif + fputs (_(\n\ +Examples:\n\ + cat first middle lastConcatenate the three files onto standard output.\n\ + cat first - last Concatenate 'first', then standard input then\n\ + 'last' onto standard output.\n\ + cat -s first lastConcatenate 'first' and 'last' to standard output\n\ + removing adjacent blank lines. [GNU only]\n\ +\n\ +), stdout); printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT); } exit (status); diff -ur ../../orig/coreutils-cvs/src/chgrp.c src/chgrp.c --- ../../orig/coreutils-cvs/src/chgrp.c2005-03-28 18:47:48.0 +0100 +++ src/chgrp.c 2005-04-03 18:50:52.0 +0100 @@ -153,6 +153,15 @@ ), stdout); fputs (HELP_OPTION_DESCRIPTION, stdout); fputs (VERSION_OPTION_DESCRIPTION, stdout); + fputs (_(\n\ +Examples:\n\ + chgrp mygroup file1 file2Change the group ownership of both files to\n\ + 'mygroup'.\n\ + chgrp mygroup -R mydir Change the group ownership of 'mydir' and\n\ + all children to 'mygroup'.\n\ + chgrp --reference=myfile file2 Change the group ownership of 'file2' to\n\ + be the same as 'myfile'. [GNU only]\n\ +), stdout); printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT); } exit (status); diff -ur ../../orig/coreutils-cvs/src/chown.c src/chown.c --- ../../orig/coreutils-cvs/src/chown.c2005-03-28 18:47:06.0 +0100 +++ src/chown.c 2005-04-03 20:32:11.0 +0100 @@ -148,6 +148,18 @@ to login group if implied by a `:' following a symbolic OWNER.\n\ OWNER and GROUP may be numeric as well as symbolic.\n\ ), stdout); + fputs (_(\n\ +Examples:\n\ + chown auser file1 file2 Change the user ownership of both files to\n\ + 'auser'.\n\ + chown -R auser mydir Change the user ownership of 'mydir' and\n\ + all its children to 'auser'.\n\ + chown auser:mygroup file1Change the user ownership of 'file1' to\n\ + 'auser' and group ownership to 'mygroup'.\n\ + chown --reference=myfile file2 Change the user and group ownership of\n\ + 'file2' to be as of 'myfile'. [GNU only]\n\ +), stdout); + printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT); } exit (status); ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Patch] Adding examples to the man pages
* Paul Eggert ([EMAIL PROTECTED]) wrote: Hmm - if you can suggest a good way to do this then I'd be happy to write the examples in any reasonable way as long as they end up in 'man' (as well as anywhere you want them). The general way is to submit a patch, in diff -u format. You'd need to patch doc/coreutils.texi and each source file (e.g., src/cp.c). No I realise that; the issue is how to include examples in the help text and let them be formatted appropriately for the man page (e.g. highlighting the fixed text and user supplied text). To be honest, this is just too much hastle; I'll go and add examples to some other packages where I just need to edit man pages. There is no point in me jumping backwards through 5 hoops to do something useful when all I really need to do is add them to the .x files. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Patch] Adding examples to the man pages
Hi, A discussion at the local Manchester LUG pointed out that many man pages don't include examples and there is a general view that it would be nice if this situation was improved. I've included a handful of examples that I've started to put together for coreutils (against 5.3.0) and would like your view on incorporating them into the distribution. I've had a quick check over this patch but there is obviously quite a bit more to do in covering the rest of the set of utilities that I am happy to complete. Suggestions and comments welcome. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ diff -urN orig/coreutils-5.3.0/man/basename.x coreutils-5.3.0/man/basename.x --- orig/coreutils-5.3.0/man/basename.x 1999-11-02 14:07:36.0 + +++ coreutils-5.3.0/man/basename.x 2005-03-13 15:20:30.0 + @@ -2,3 +2,14 @@ basename \- strip directory and suffix from filenames [DESCRIPTION] .\ Add any additional description here +[EXAMPLES] +.TP +.B basename \fI/an/example/path/finalname\fR +.br +Strip off the path leaving just \fIfinalname\fR. +.TP +.B basename \fIthe/path/finalname.foo\fR \fI.foo\fR +.br +Stip off the path and the trailing \fI.foo\fR leaving \fIfinalname\fR. Note +that if the name did not end in \fI.foo\fR the full basename would be passed +through. diff -urN orig/coreutils-5.3.0/man/cat.x coreutils-5.3.0/man/cat.x --- orig/coreutils-5.3.0/man/cat.x 1999-11-02 13:58:56.0 + +++ coreutils-5.3.0/man/cat.x 2005-03-13 15:41:14.0 + @@ -1,4 +1,20 @@ [NAME] cat \- concatenate files and print on the standard output +[EXAMPLES] +.TP +.B cat \fIfirst\fR \fImiddle\fR \fIlast\fR +.br +Concatenate the three files \fIfirst\fR \fImiddle\fR \fIlast\fR onto the standard output. +.TP +.B cat \fIheader\fR \fB-\fR \fIfooter\fR +.br +Concatenate the two files \fIheader\fR and \fIfooter\fR putting the contents of standard +input in between; the result is placed onto the standard output. +.TP +.B cat -s +.br +Squeeze multiple blank lines from standard input down to a single blank; the result is +placed onto the standard output. Standard output is only read if no filenames are given +or if \fB-\fR is used. [DESCRIPTION] .\ Add any additional description here diff -urN orig/coreutils-5.3.0/man/chgrp.x coreutils-5.3.0/man/chgrp.x --- orig/coreutils-5.3.0/man/chgrp.x2000-02-01 10:34:35.0 + +++ coreutils-5.3.0/man/chgrp.x 2005-03-13 16:07:26.0 + @@ -2,3 +2,13 @@ chgrp \- change group ownership [DESCRIPTION] .\ Add any additional description here +[EXAMPLES] +.TP +.B chgrp \fImygroup\fR \fIfile1\fR \fIfile2\fR +.br +Change the group ownership of \fIfile1\fR and \fIfile2\fR to \fImygroup\fR. +.TP +.B chgrp -R --reference=\fImyreffile\fR \fI/usr/myexampledir\fR +.br +Change the group ownership of the directory \fI/usr/myexampledir\fR and +all files under it to be the same as that of \fImyreffile\fR. diff -urN orig/coreutils-5.3.0/man/chown.x coreutils-5.3.0/man/chown.x --- orig/coreutils-5.3.0/man/chown.x2001-10-13 17:50:59.0 +0100 +++ coreutils-5.3.0/man/chown.x 2005-03-13 17:19:21.0 + @@ -20,3 +20,19 @@ performs the same function as .BR chgrp . .SH OPTIONS +[EXAMPLES] +.TP +.B chown \fIauser\fR \fIfile1\fR \fIfile2\fR +.br +Change the user ownership of \fIfile1\fR and \fIfile2\fR to \fIauser\fR which +may be either a name or numerical user ID. The group ID of the files is left +unchanged. +.TP +.B chown -R \fIauser:agroup\fR \fIadirectory\fR +.br +Change the user and group ownership of \fIadirectory\fR and all the files +and directories under it to \fIauser\fR and \fIagroup\fR respectively. +.TP +.B chown --reference \fIonefile\fR \fIanotherfile\fR +.br +Change the user and group of \fIanotherfile\fR to match that of \fIonefile\fR. diff -urN orig/coreutils-5.3.0/man/chroot.x coreutils-5.3.0/man/chroot.x --- orig/coreutils-5.3.0/man/chroot.x 1999-11-02 14:07:36.0 + +++ coreutils-5.3.0/man/chroot.x2005-03-13 17:25:56.0 + @@ -2,3 +2,14 @@ chroot \- run command or interactive shell with special root directory [DESCRIPTION] .\ Add any additional description here +[EXAMPLES] +.TP +.B chroot \fIdirectory\fR +.br +Substitute \fIdirectory\fR as / and execute the /bin/sh under that root in the +new environment. +.TP +.B chroot \fI/my/new/install\fR \fI/bin/bash\fR +.br +Execute \fI/my/new/install/bin/bash\fR in an environment with \fI/my/new/install\fR +as /. diff -urN orig/coreutils-5.3.0/man/cksum.x coreutils-5.3.0/man/cksum.x --- orig/coreutils-5.3.0/man/cksum.x1999-11-02 13:58:56.0 + +++ coreutils-5.3.0/man/cksum.x 2005-03-13 18:10:18.0 + @@ -2,3 +2,9 @@ cksum \- checksum and count the bytes in a file
