Re: Why not enhance sort to handle floating point numbers?
On Fri, 7 Nov 2008, Steve Wald wrote: It would be real handy if sort had an option analogous to -n which would properly handle columns of exponential notation numbers, e.g. -9.575e-08, or even if the -n option itself would detect and sort them. Much of my data is mixed exponential and decimal notation. You're in luck - sort's -g option does exactly this. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
On Fri, Nov 7, 2008 at 8:39 AM, Jim Meyering [EMAIL PROTECTED] wrote:
Have you considered adding SELinux-related format directives to GNU find?
I would likely accept such patches into find, subject to a GNU
copyright assignment of course.
More generally, a more flexible syntax for find's -printf formats
might be useful. Because of the limited number of format directive
letters remaining unused in find, I have been thinking about
directives based on names. This might look like %20.18{pathname}s,
%{filemode}o %{filemode}d and so on. It's inappropriate to
complicate the format directives completely to the point where find
has an embedded string formatting language though (as well as its
embedded filesystem predicate language). If somebody did this work it
would probably make sense to refactor the code a bit such that the
formatting implementation could be lifted out as a module and re-used
elsewhere.
If you're interested in pursuing this (either the SELinux format
enhancements or the more ambitious change), please email
[EMAIL PROTECTED]
Thanks.
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Threaded versions of cp, mv, ls for high latency / parallel filesystems?
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. 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.) 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.) To the user, it could look very much the same ... export GNU_COREUTILS_THREADS=8 cp # manipulate multiple files simultaneously mv # manipulate multiple files simultaneously ls # stat() multiple files simultaneously 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. :-) ___ 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. How about parallelizing it via xargs, e.g., $ echo a b c d e f g h | xargs -t -n4 --no-run-if-empty \ --max-procs=2 -- cp --target-directory=dest cp --target-directory=dest a b c d cp --target-directory=dest e f g h Obviously the above is tailored (-L4) to your 8-input example. In practice, you'd use a larger number, unless latency is so high as to dwarf the cost of extra fork/exec syscalls, in which case even -L1 might make sense. mv and ln also accept the --target-directory=dest option. 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 If you can demonstrate a large performance gain on systems that many people use, then maybe... There is more than a little value in keeping programs like those in the coreutils package relatively simple, but if the cost(maintenance+portability burden)/benefit ratio is low enough, then anything is possible. For example, a well-encapsulated, optionally-threaded stat_all_dir_entries API might be useful in some situations. If getting any eventual patch into upstream coreutils is important to you, be sure there is some consensus on this list before doing a lot of work on it. display. (This could improve performance for NFS, in proportion to the latency and the number of threads.) Question: Is there already a set of improved utilities that implement this kind of technique? Not that I know of. If not, would this kind of performance enhancements be considered useful? It's impossible to say without knowing more. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
Ondřej Vašík [EMAIL PROTECTED] wrote:
I googled a bit about that french issue, it was already reported to
translation team. Answer was that it could be caused by translation like
report all bugs to [EMAIL PROTECTED] instead of report bugs to
[EMAIL PROTECTED] . I don't think so, I guess it is too similar to
cause such confusion, I would prefer formulation like report bugs
related to programname utility to bug-coreutils@gnu.org anyway ...
will check if it is acceptable by upstream...
Thanks for pursuing that.
I like the idea and will probably address it with a change like this:
diff --git a/src/system.h b/src/system.h
index e88b1bb..8577d44 100644
--- a/src/system.h
+++ b/src/system.h
@@ -614,11 +614,12 @@ ptr_align (void const *ptr, size_t alignment)
static inline void
emit_bug_reporting_address (void)
{
- /* TRANSLATORS: The placeholder indicates the bug-reporting address
- for this package. Please add _another line_ saying
- Report translation bugs to ...\n with the address for translation
+ /* TRANSLATORS: The second placeholder indicates the bug-reporting
+ address for this package. Please add _another line_ saying
+ Report %s translation bugs to ...\n with the address for translation
bugs (typically your translation team's web or email address). */
- printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
+ printf (_(\nReport %s bugs to %s.\n), last_component (program_name),
+ PACKAGE_BUGREPORT);
}
#include inttostr.h
___
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?
On Sat, Nov 8, 2008 at 6:05 PM, Jim Meyering [EMAIL PROTECTED] wrote: How about parallelizing it via xargs, e.g., $ echo a b c d e f g h | xargs -t -n4 --no-run-if-empty \ --max-procs=2 -- cp --target-directory=dest cp --target-directory=dest a b c d cp --target-directory=dest e f g h For tools lacking a --target-directory option there is this shell trick: $ echo a b c d e f g h | xargs -n4 --no-run-if-empty --max-procs=2 -- sh -c 'prog $@ destination' prog James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
On Sat, 2008-11-08 at 19:51 +0100, Jim Meyering wrote:
Ondřej Vašík [EMAIL PROTECTED] wrote:
I googled a bit about that french issue, it was already reported to
translation team. Answer was that it could be caused by translation like
report all bugs to [EMAIL PROTECTED] instead of report bugs to
[EMAIL PROTECTED] . I don't think so, I guess it is too similar to
cause such confusion, I would prefer formulation like report bugs
related to programname utility to bug-coreutils@gnu.org anyway ...
will check if it is acceptable by upstream...
Thanks for pursuing that.
I like the idea and will probably address it with a change like this:
diff --git a/src/system.h b/src/system.h
index e88b1bb..8577d44 100644
--- a/src/system.h
+++ b/src/system.h
@@ -614,11 +614,12 @@ ptr_align (void const *ptr, size_t alignment)
static inline void
emit_bug_reporting_address (void)
{
- /* TRANSLATORS: The placeholder indicates the bug-reporting address
- for this package. Please add _another line_ saying
- Report translation bugs to ...\n with the address for translation
+ /* TRANSLATORS: The second placeholder indicates the bug-reporting
+ address for this package. Please add _another line_ saying
+ Report %s translation bugs to ...\n with the address for translation
bugs (typically your translation team's web or email address). */
- printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
+ printf (_(\nReport %s bugs to %s.\n), last_component (program_name),
+ PACKAGE_BUGREPORT);
}
#include inttostr.h
A run with 'LC_ALL=fr_FR.utf8 chown --help' produced the 'report a bug'
as:
Signaler un bug à bug-coreutils@gnu.org.
This is, literally, report a bug to
Perhaps it might be another option to ask distributions to replace the
string with a report a bug to distribution BTS.
Regards,
signature.asc
Description: This is a digitally signed message part
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
Perhaps something like the attached patch to the usage message might be worthwhile (though I think it is probably too wordy). James. From 54614d88bc91d0c188108b467fb518c7d3de7c06 Mon Sep 17 00:00:00 2001 From: James Youngman [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 21:55:50 + Subject: [PATCH] install: indicate clearly it's not for installing packages. To: bug-coreutils@gnu.org * src/instrall.c (usage): Indicate the program copies binary files, as opposed to installing packages. --- src/install.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/install.c b/src/install.c index a7c3b3d..a320868 100644 --- a/src/install.c +++ b/src/install.c @@ -816,6 +816,14 @@ Usage: %s [OPTION]... [-T] SOURCE DEST\n\ ), program_name, program_name, program_name, program_name); fputs (_(\ +\n\ +The install utility copies files (which you will normally have recently\n\ +compiled) into the location you decided to install them. If in fact you\n\ +want to download and install a ready-to-use package instead of compiling it\n\ +yourself, you should probably be using different program. The right choice\n\ +of program depends on your operating system. Popular choices for GNU/Linux\n\ +systems are yum(1) and apt-get(1).\n\ +\n\ In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to\n\ the existing DIRECTORY, while setting permission modes and owner/group.\n\ In the 4th form, create all components of the given DIRECTORY(ies).\n\ -- 1.5.6.5 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Ubuntu 8.10 CD Image
Greetings: I have downloaded the new Ubuntu 8.10 CD Image and it is not recognized by a system (CD) currently running Ubuntu 8.04. Why? -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Ubuntu 8.10 CD Image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Al Jorge on 11/8/2008 4:04 PM: Greetings: I have downloaded the new Ubuntu 8.10 CD Image and it is not recognized by a system (CD) currently running Ubuntu 8.04. Why? After recent Ubuntu releases there have been several people who have been asking about Ubuntu questions on this GNU Coreutils mailing list. If you would be so kind could you tell us what has directed you to ask your question on this mailing list? We fear that there may be incorrect documentation pointing you here. If you would help us so that we could improve the directions it would help others. Thanks! 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 Ubuntu's applications. I am sorry but this is the wrong mailing list. We are unable to help you here. Since you are using Ubuntu then the Ubuntu users mailing lists would be a better source of information. http://www.ubuntu.com/support/communitysupport http://www.ubuntu.com/support/community/mailinglists - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -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 iEYEARECAAYFAkkWXUkACgkQ84KuGfSFAYDViwCfQs0meTPytV6y/GRZBuZh1bcD HFAAn1jJMZNgSbCI7HTrroHMuZ23DgE0 =rYHi -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 294348] Re: ubuntu directing users to coreutils mailing list for general problems
James Youngman [EMAIL PROTECTED] wrote: Perhaps something like the attached patch to the usage message might be worthwhile (though I think it is probably too wordy). Thank you. I agree. How about this? From 1ae69757c63e2d0d7e1103f7d17d7d256d625e55 Mon Sep 17 00:00:00 2001 From: James Youngman [EMAIL PROTECTED] Date: Sat, 8 Nov 2008 21:55:50 + Subject: [PATCH] install: indicate clearly it's not for installing packages * src/install.c (usage): Indicate the program copies files, as opposed to installing packages. --- src/install.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/install.c b/src/install.c index a7c3b3d..3f085af 100644 --- a/src/install.c +++ b/src/install.c @@ -816,6 +816,12 @@ Usage: %s [OPTION]... [-T] SOURCE DEST\n\ ), program_name, program_name, program_name, program_name); fputs (_(\ +\n\ +This install program copies files (often just compiled) into destination\n\ +locations you choose. If you want to download and install a ready-to-use\n\ +package on a GNU/Linux system, you should be using a package manager\n\ +like yum(1) or apt-get(1).\n\ +\n\ In the first three forms, copy SOURCE to DEST or multiple SOURCE(s) to\n\ the existing DIRECTORY, while setting permission modes and owner/group.\n\ In the 4th form, create all components of the given DIRECTORY(ies).\n\ -- 1.6.0.3.866.gc189b ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
