FYI: rm --interactive=never F no longer prompts for an unwritable F
I noticed that rm's new --interactive=[WHEN] option didn't work properly
in some cases. For example, this use of rm would prompt, contradicting
the semantics of --interactive=never:
$ touch unwritable
$ chmod -w unwritable
$ rm --interactive=never unwritable
rm: remove write-protected regular empty file `unwritable'?
With the fix below, it is no longer interactive.
Make rm --interactive=never ... never prompt.
* NEWS: Mention this.
* src/remove.h (enum rm_interactive): New ternary type.
(struct rm_options) [interactive]: Use it, here -- rather than bool.
* src/remove.c (prompt): Reflect type change.
* src/mv.c (rm_option_init): Initialize to RMI_NEVER now.
* src/rm.c (main): Add a FIXME comment for '-d' option.
Adapt to type change of rm_options.interactive.
* tests/rm/i-never: New file. Test for the above fix.
* tests/rm/Makefile.am (TESTS): Add i-never.
Here's a link to the same change-set:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0928c2414a
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
NEWS |2 +
ChangeLog| 14 +
src/mv.c |4 +-
src/remove.c | 10 ++--
src/remove.h | 13 ++-
src/rm.c | 18
tests/rm/Makefile.am |3 +-
tests/rm/i-never | 53 ++
8 files changed, 100 insertions(+), 17 deletions(-)
diff --git a/NEWS b/NEWS
index 76f90d3..a30b17e 100644
--- a/NEWS
+++ b/NEWS
@@ -27,6 +27,8 @@ GNU coreutils NEWS-*-
outline -*-
rm -rf /etc/passwd (run by non-root) now prints a diagnostic.
Before it would print nothing.
+ rm --interactive=never F no longer prompts for an unwritable F
+
* Noteworthy changes in release 6.7 (2006-12-08) [stable]
diff --git a/ChangeLog b/ChangeLog
index b82902a..7a80dbf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2007-01-17 Jim Meyering [EMAIL PROTECTED]
+
+ Make rm --interactive=never ... never prompt.
+ * NEWS: Mention this.
+ * src/remove.h (enum rm_interactive): New ternary type.
+ (struct rm_options) [interactive]: Use it, here -- rather than bool.
+ * src/remove.c (prompt): Reflect type change.
+ * src/mv.c (rm_option_init): Initialize to RMI_NEVER now.
+ * src/rm.c (main): Add a FIXME comment for '-d' option.
+ Adapt to type change of rm_options.interactive.
+
+ * tests/rm/i-never: New file. Test for the above fix.
+ * tests/rm/Makefile.am (TESTS): Add i-never.
+
2007-01-15 Jim Meyering [EMAIL PROTECTED]
* bootstrap (gnulib_tool): When adding to .cvsignore and .gitignore,
diff --git a/src/mv.c b/src/mv.c
index 03e96e5..1d1ddda 100644
--- a/src/mv.c
+++ b/src/mv.c
@@ -1,5 +1,5 @@
/* mv -- move or rename files
- Copyright (C) 86, 89, 90, 91, 1995-2006 Free Software Foundation, Inc.
+ Copyright (C) 86, 89, 90, 91, 1995-2007 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -98,7 +98,7 @@ rm_option_init (struct rm_options *x)
/* Should we prompt for removal, too? No. Prompting for the `move'
part is enough. It implies removal. */
- x-interactive = 0;
+ x-interactive = RMI_NEVER;
x-stdin_tty = false;
x-verbose = false;
diff --git a/src/remove.c b/src/remove.c
index fbe7204..97184eb 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -798,10 +798,14 @@ prompt (int fd_cwd, Dirstack_state const *ds, char const
*filename,
*is_empty = T_UNKNOWN;
- if (((!x-ignore_missing_files (x-interactive | x-stdin_tty))
+ if (x-interactive == RMI_NEVER)
+return RM_OK;
+
+ if (((!x-ignore_missing_files ((x-interactive == RMI_ALWAYS)
+ | x-stdin_tty))
(write_protected = write_protected_non_symlink (fd_cwd, filename,
ds, sbuf)))
- || x-interactive)
+ || x-interactive == RMI_ALWAYS)
{
if (cache_fstatat (fd_cwd, filename, sbuf, AT_SYMLINK_NOFOLLOW) != 0)
{
@@ -821,7 +825,7 @@ prompt (int fd_cwd, Dirstack_state const *ds, char const
*filename,
/* Using permissions doesn't make sense for symlinks. */
if (S_ISLNK (sbuf-st_mode))
{
- if ( ! x-interactive)
+ if (x-interactive != RMI_ALWAYS)
return RM_OK;
write_protected = false;
}
diff --git a/src/remove.h b/src/remove.h
index 2dc6176..ae01e3c 100644
--- a/src/remove.h
+++ b/src/remove.h
@@ -1,6 +1,6 @@
/* Remove directory entries.
- Copyright (C) 1998, 2000, 2002, 2003, 2004, 2005, 2006 Free
+ Copyright (C) 1998, 2000, 2002, 2003, 2004, 2005, 2006, 2007 Free
Software Foundation, Inc.
This program is free software; you can redistribute it and/or
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
On 2007-01-15 21:05:53 -0600, Vincent Lefevre [EMAIL PROTECTED] said: Hi, Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via MacPorts), in a 80-column terminal (uxterm), I get: $ ls É y123456789012345678901234567890 x123456789012345678901234567890 z123456789012345678901234567890 instead of: $ ls Éy123456789012345678901234567890 x123456789012345678901234567890 z123456789012345678901234567890 Note: $ locale LANG=POSIX LC_COLLATE=POSIX LC_CTYPE=en_US.UTF-8 LC_MESSAGES=POSIX LC_MONETARY=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_ALL=POSIX/en_US.UTF-8/POSIX/POSIX/POSIX/POSIX Regards, How to reproduce, please? Does changing the Apple Terminal Window Settings aka Terminal Inspector help? In particular, select the tab named Display, and try the first three checkmarks under the Text Font section there. Sometimes the Anti-Alias setting is enough to push the width of the character cell over to make the rest of the printed line line-up properly. The next two checkmarks are for wide glyphs, sometimes Terminal needs to be fooled with these settings for accented chars anyway. How does iTerm behave? They've been working on some enhancements of their own (nevermind Apple ;) ). -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Vincent Lefevre wrote:
Hmm... I forgot that ls was an alias (the same one on all my accounts).
So, back on Mac OS X:
prunille:~/blah \ls -C --color=always | hexdump -C
1b 5b 30 30 6d 1b 5b 30 6d 45 cc 81 1b 5b 30 30 |.[00m.[0mE�..[00|
0010 6d 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |m |
0020 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ||
0030 1b 5b 30 6d 79 31 32 33 34 35 36 37 38 39 30 31 |.[0my12345678901|
0040 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 |2345678901234567|
0050 38 39 30 1b 5b 30 30 6d 0a 1b 5b 30 6d 78 31 32 |890.[00m..[0mx12|
0060 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 |3456789012345678|
0070 39 30 31 32 33 34 35 36 37 38 39 30 1b 5b 30 30 |901234567890.[00|
0080 6d 20 20 1b 5b 30 6d 7a 31 32 33 34 35 36 37 38 |m .[0mz12345678|
0090 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 |9012345678901234|
00a0 35 36 37 38 39 30 1b 5b 30 30 6d 0a 1b 5b 6d |567890.[00m..[m|
00af
That makes - except for the escape sequences - an E, a combining accent and
31 spaces. So it's the same bug as in ls -C -T0.
I see that the first call to wcwidth() gives: wcwidth(0x0301) = 1.
U+0301 is COMBINING ACUTE ACCENT. So here is the problem: MacOS'
wcwidth is buggy for combining characters like accents.
OK. Can't autoconf detect that and use another implementation?
Yes. We can do that in gnulib. I'll work on this issue in the next few weeks.
Please remind us (on the bug-gnulib mailing list) in 1 or 2 months.
And, as we have seen, the other issue is that Apple Terminal has problems
estimating the width of tabs when there are non-ASCII characters. Since
you can start an telnet/ssh session from MacOS X to any platform (Linux,
Solaris, etc.), the fix needs to be platform independent. Here is such a fix:
2007-01-18 Bruno Haible [EMAIL PROTECTED]
Avoid problems with tabs after non-ASCII characters in some terminals.
* src/ls.c (nonascii_in_this_line): New variable.
(quote_name): Update nonascii_in_this_line.
(print_many_per_line, print_horizontal): Set nonascii_in_this_line to
false at the beginning of each line.
(indent): Use spaces for indentation when nonascii_in_this_line.
diff -c -3 -r1.447 ls.c
*** src/ls.c2 Jan 2007 06:29:12 - 1.447
--- src/ls.c18 Jan 2007 14:38:14 -
***
*** 851,856
--- 851,859
for the separating white space. */
#define MIN_COLUMN_WIDTH 3
+ /* True if some non-ASCII character has been output on this line. */
+ static bool nonascii_in_this_line;
+
/* This zero-based index is used solely with the --dired option.
When that option is in effect, this counter is incremented for each
***
*** 3704,3710
}
if (out != NULL)
! fwrite (buf, 1, len, out);
if (width != NULL)
*width = displayed_width;
return len;
--- 3702,3722
}
if (out != NULL)
! {
! /* Update nonascii_in_this_line indicator. */
! char const *p = buf;
! char const *plimit = buf + len;
!
! for (; p plimit; p++)
! if (!isascii (to_uchar (*p)))
! {
! nonascii_in_this_line = true;
! break;
! }
!
! /* Actually output the quoted representation. */
! fwrite (buf, 1, len, out);
! }
if (width != NULL)
*width = displayed_width;
return len;
***
*** 3957,3962
--- 3969,3975
size_t pos = 0;
/* Print the next row. */
+ nonascii_in_this_line = false;
while (1)
{
size_t name_length = length_of_file_name_and_frills (files + filesno);
***
*** 3984,3989
--- 3997,4004
size_t name_length = length_of_file_name_and_frills (files);
size_t max_name_length = line_fmt-col_arr[0];
+ nonascii_in_this_line = false;
+
/* Print first entry. */
print_file_name_and_frills (files);
***
*** 3996,4001
--- 4011,4017
{
putchar ('\n');
pos = 0;
+ nonascii_in_this_line = false;
}
else
{
***
*** 4047,4060
}
/* Assuming cursor is at position FROM, indent up to position TO.
!Use a TAB character instead of two or more spaces whenever possible. */
static void
indent (size_t from, size_t to)
{
while (from to)
{
! if (tabsize != 0 to / tabsize (from + 1) / tabsize)
{
putchar ('\t');
from += tabsize - from % tabsize;
--- 4063,4085
}
/* Assuming cursor is at position FROM, indent up to position TO.
!Use a TAB character instead of two or more spaces whenever possible.
!Depends on the TABSIZE option and on the current value of
!NONASCII_IN_THIS_LINE. */
static void
indent (size_t from, size_t to)
{
while (from
Re: Build failure on AIX 4.3
Jim, That did the trick. The coreutils tarball you provided builds (and tests) without a hitch on the same AIX 4.3 system. Thanks for the fix :) --Daniel On Mon, 2007 Jan 15 16:41:04 +0100, Jim Meyering wrote: Thanks for the report and analysis. Here's a proposed patch for the gnulib readutmp module: * m4/readutmp.m4 (gl_READUTMP): Work around AIX 4.3 struct- redefinition bug when using both utmp.h and utmpx.h headers. * lib/readutmp.h: Likewise. Reported by Daniel Richard G. in http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/9415. Here's a test tarball with that patch and all of the latest bits, in case that makes it easier for you to test: http://meyering.net/cu/coreutils-6.7-dirty.tar.gz http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig Please try it and let us know. -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = [EMAIL PROTECTED]## don't smell bad---(/o|o\) / EMAIL2 = [EMAIL PROTECTED] ## it's the people who(^), WWW= http://www.**.org/ ## annoy them that do!/ \ -- (** = site not yet online) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Pb avec aMule 2.1.3
Madame, monsieur, May you help me, cause I'm a very newbie with Linux...Thanks... HAPPY NEW YEAR ! 2007..and so on... [EMAIL PROTECTED] aMule-2.1.3]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking whether make sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for bison... no checking for byacc... no checking for ranlib... (cached) ranlib checking for strip... strip checking for ar... ar checking for ld... ld checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for zlib = 1.1.4... yes (version 1.2.3) checking whether we need the GUI... yes checking for wx-config... /usr/bin/wx-config checking for wxWidgets version = 2.6.0... yes (version 2.6.3) checking for wxWidgets static library... no checking that wxWidgets has support for large files... yes checking whether to use embedded Crypto... yes checking for bfd headers... no configure: WARNING: bfd.h not found, please install binutils development package if you are a developer or want to help testing aMule checking for autopoint... ./configure: line 8223: autopoint: command not found no () configure: You need to install GNU gettext/gettext-tools to compile aMule with i18n support checking for extended flex capabilities... ./configure: line 8246: flex: command not found no configure: Your flex version doesn't support --header-file flag. This is not critical, but an upgrade is recommended checking for X... libraries , headers checking for working alloca.h... yes checking for alloca... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for ANSI C header files... (cached) yes checking argz.h usability... yes checking argz.h presence... yes checking for argz.h... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for inttypes.h... (cached) yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking mntent.h usability... yes checking mntent.h presence... yes checking for mntent.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdint.h... (cached) yes checking stdio_ext.h usability... yes checking stdio_ext.h presence... yes checking for stdio_ext.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/mount.h
Re: FYI: rm --interactive=never F no longer prompts for an unwritable F
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: * tests/rm/i-never: New file. Test for the above fix. diff --git a/tests/rm/i-never b/tests/rm/i-never new file mode 100755 Unfortunately that did not make it into the CVS repository as mode 755 but instead is 644 there. Our old friend the mode problem on new test files has appeared again. Can you sync this up into the CVS repository? Hi Bob! Thanks for letting me know. I think this is because we're using too old a version of git-cvsexportcommit. I'll fix that, too. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Bruno Haible [EMAIL PROTECTED] wrote: Vincent Lefevre wrote: ... I see that the first call to wcwidth() gives: wcwidth(0x0301) = 1. U+0301 is COMBINING ACUTE ACCENT. So here is the problem: MacOS' wcwidth is buggy for combining characters like accents. OK. Can't autoconf detect that and use another implementation? Yes. We can do that in gnulib. I'll work on this issue in the next few weeks. Please remind us (on the bug-gnulib mailing list) in 1 or 2 months. Thanks for volunteering to do that. And, as we have seen, the other issue is that Apple Terminal has problems estimating the width of tabs when there are non-ASCII characters. Since you can start an telnet/ssh session from MacOS X to any platform (Linux, Solaris, etc.), the fix needs to be platform independent. Here is such a fix: 2007-01-18 Bruno Haible [EMAIL PROTECTED] Avoid problems with tabs after non-ASCII characters in some terminals. * src/ls.c (nonascii_in_this_line): New variable. (quote_name): Update nonascii_in_this_line. (print_many_per_line, print_horizontal): Set nonascii_in_this_line to false at the beginning of each line. (indent): Use spaces for indentation when nonascii_in_this_line. Thank you for working on this. As I understand the goal, you'd like to make ls act differently (outputting spaces, not TABs, for column alignment) on all systems for each line containing a non-ASCII byte. The proposed change in behavior would serve solely to make it so columns line up better when displaying on a buggy Apple Terminal. That change would contradict the documentation of -T, but more importantly, it would make the output significantly larger when there are wide columns and many lines containing a non-ASCII byte, thus penalizing all users in order to cater to a buggy terminal emulator. I would rather simply have someone who cares about Apple Terminal report the bug, and in the mean time, advise people to use -T0 (or set TABSIZE=0 in their environment) if they care about alignment when using a buggy version of that particular terminal emulator. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: does df can list sort by size
Samuel Wong wrote: I want to list the usage sort by Size. How Can I list sort by Size. Best bet might be to join the people wanting 'sort' to sort more intelligently. :-) Like, for example, understanding how to sort human-readable sizes. This would help out 'du' also... -- Matthew What a wonderful smell you've discovered! -- Princess Leia Organa ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Jim Meyering wrote: As I understand the goal, you'd like to make ls act differently (outputting spaces, not TABs, for column alignment) on all systems for each line containing a non-ASCII byte. Yes, this is what the proposed patch does. That change would contradict the documentation of -T The --color option also has the effect of turning tabs into spaces; yet this is undocumented. Actually the doc states `ls' uses tabs where possible in the output, for efficiency. If COLS is zero, do not use tabs at all. and the phrase where possible is vague enough. It is not possible to use tabs with --color, and it is not possible to use tabs after non-ASCII characters. but more importantly, it would make the output significantly larger when there are wide columns and many lines containing a non-ASCII byte, thus penalizing all users in order to cater to a buggy terminal emulator. I thought with xterm, as with most terminal emulators, the network transmit time is negligible compared to the rendering time on the X side. Besides that, your argument trades correctness of display against efficiency. I would rather simply have someone who cares about Apple Terminal report the bug, and in the mean time, advise people to use -T0 (or set TABSIZE=0 in their environment) if they care about alignment when using a buggy version of that particular terminal emulator. Vincent, do you have time to report that to the Apple people? No need to mention 'ls' - a simple printf 'E\xcc\x81\t2nd column\nFoo\t2nd column\n' should be all you need to demonstrate the bug. I'm not in such a good position to report it, since I'm using an older version of MacOS X. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote: As I understand the goal, you'd like to make ls act differently (outputting spaces, not TABs, for column alignment) on all systems for each line containing a non-ASCII byte. Yes, this is what the proposed patch does. That change would contradict the documentation of -T The --color option also has the effect of turning tabs into spaces; yet this is undocumented. Actually the doc states `ls' uses tabs where possible in the output, for efficiency. If COLS is zero, do not use tabs at all. and the phrase where possible is vague enough. It is not possible to use tabs with --color, and it is not possible to use tabs after non-ASCII characters. Um... it *is* possible to use TABs after non-ASCII bytes and get correct alignment. The only requirement is that you be using a reasonable (non-buggy) terminal emulator. but more importantly, it would make the output significantly larger when there are wide columns and many lines containing a non-ASCII byte, thus penalizing all users in order to cater to a buggy terminal emulator. I thought with xterm, as with most terminal emulators, the network transmit time is negligible compared to the rendering time on the X side. Besides that, your argument trades correctness of display against efficiency. Not at all. I merely refuse to pessimize ls output for everyone, solely to accommodate some currently buggy version of Apple Terminal. I would rather simply have someone who cares about Apple Terminal report the bug, and in the mean time, advise people to use -T0 (or set TABSIZE=0 in their environment) if they care about alignment when using a buggy version of that particular terminal emulator. Do you really think it would be better to make everyone pay (even a tiny bit) when there is such an easy work-around? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Jim Meyering wrote: Um... it *is* possible to use TABs after non-ASCII bytes and get correct alignment. The only requirement is that you be using a reasonable (non-buggy) terminal emulator. Yes, sure. I was only pointing out that the proposed change wouldn't need a doc change, because the wording in the doc is already vague. in the mean time, advise people to use -T0 (or set TABSIZE=0 in their environment) if they care about alignment when using a buggy version of that particular terminal emulator. Do you really think it would be better to make everyone pay (even a tiny bit) when there is such an easy work-around? Given that - Apple Terminal is the default/normal terminal emulator on MacOS X, - networking/pipe speed are not critical nowadays (in the times of internet radio and streaming video), - the bug was tricky enough to analyze, that an average user couldn't do it by himself, I would say yes in this case. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: gzip/bzip support for sort
Jim Meyering [EMAIL PROTECTED] wrote: Dan Hipschman [EMAIL PROTECTED] wrote: On Sat, Jan 13, 2007 at 10:07:59PM -0800, Paul Eggert wrote: 3. I can see where the user might be able to specify a better algorithm, for a particular data set. For that, how about if we have a --compress-program=PROGRAM option, which lets the user plug in any program that works as a pipeline? E.g., --compress-program=gzip would use gzip. The default would be to use PROGRAM -d to decompress; we could have another option if that doesn't suffice. This is pretty close. There is just a few more problems that I see: One more thing to consider: In your proposed patch, a failed fork evokes an immediate exit. In that case, it may be worthwhile to retry, or even to revert to using gzip directly. Upon rereading, I see the latter part is not clear. I mean resorting to the use of a direct (non-forking) implementation, like libz. This, of course, assumes we're using gzip. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Savannah-hackers-public] Re: FYI: rm --interactive=never F no longer prompts for an unwritable F
Sylvain Beucler [EMAIL PROTECTED] wrote: As far as I can see, we use 1.4.4.4 which is the latest released version (excluding release candidates ;)). Problem? I'll let you know. I'm working on reproducing the inputs for the failed git-cvsexportcommit. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: gzip/bzip support for sort
On Thu, 18 Jan 2007, Jim Meyering wrote: I've done some more timings, but with two more sizes of input. Here's the summary, comparing straight sort with sort --comp=gzip: 2.7GB: 6.6% speed-up 10.0GB: 17.8% speed-up It would be interesting to see the individual stats returned by wait4(2) from the child, to separate CPU seconds spent in sort itself, and in the compression/decompression forks. I think allowing an environment variable to define the compressor is a good idea, so long as there's a corresponding --nocompress override available from the command line. $ seq 999 k $ cat k k k k k k k k k j $ cat j j j j sort-in $ wc -c sort-in 283968 sort-in I had to use seq -f %.0f to get this filesize. With --compress=gzip: $ /usr/bin/time ./sort -T. --compress=gzip sort-in out 814.07user 29.97system 14:50.16elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (4major+2821589minor)pagefaults 0swaps There's a big difference in the time spent on gzip compression depending on the -1/-9 option (default -6). For a similar seq-generated data set above, I get gzip -1: User time (seconds): 48.63, output size is 6% of input gzip -9: User time (seconds): 952.97, output size is 3% of input Decompression time for both tests shows less variation (25s vs 21s). This would suggest the elapsed time to sort can be improved by trading compression ratio for less CPU time. Obviously a critical factor is the disk latency. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: gzip/bzip support for sort
Philip Rowlands [EMAIL PROTECTED] wrote: On Thu, 18 Jan 2007, Jim Meyering wrote: I've done some more timings, but with two more sizes of input. Here's the summary, comparing straight sort with sort --comp=gzip: 2.7GB: 6.6% speed-up 10.0GB: 17.8% speed-up It would be interesting to see the individual stats returned by wait4(2) from the child, to separate CPU seconds spent in sort itself, and in the compression/decompression forks. I think allowing an environment variable to define the compressor is a good idea, so long as there's a corresponding --nocompress override available from the command line. $ seq 999 k $ cat k k k k k k k k k j $ cat j j j j sort-in $ wc -c sort-in 283968 sort-in I had to use seq -f %.0f to get this filesize. Odd. Here's what those generate for me: $ seq 999 k $ wc -c k 7888 $ tail -1 k 999 The remaining cat commands merely write 36 copies of that data to sort-in: $ (wc -c k|tr -d '\n'; echo '* 36')|bc 283968 What happens differently for you? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Bruno Haible [EMAIL PROTECTED] wrote: in the mean time, advise people to use -T0 (or set TABSIZE=0 in their environment) if they care about alignment when using a buggy version of that particular terminal emulator. Do you really think it would be better to make everyone pay (even a tiny bit) when there is such an easy work-around? Given that - Apple Terminal is the default/normal terminal emulator on MacOS X, - networking/pipe speed are not critical nowadays (in the times of internet radio and streaming video), - the bug was tricky enough to analyze, that an average user couldn't do it by himself, I would say yes in this case. We disagree. IMHO, it would be unwise to make such a global sacrifice for a single, buggy, closed-source terminator emulator. However, if someone tells me which version of Apple Terminal is affected, I'll mention the work-around in the coreutils README file. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: gzip/bzip support for sort
On Thu, 18 Jan 2007, Jim Meyering wrote: I had to use seq -f %.0f to get this filesize. Odd. Here's what those generate for me: $ seq 999 k $ wc -c k 7888 $ tail -1 k 999 What happens differently for you? $ seq 990 999 9.9e+06 9.9e+06 9.9e+06 9.9e+06 9.9e+06 1e+07 1e+07 1e+07 1e+07 1e+07 [EMAIL PROTECTED]:~$ seq --version seq (GNU coreutils) 5.93 I'm using an old version of seq with a different default format (I didn't realised it had changed recently.) Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
Paul Eggert wrote: Long ago I regularly used terminal emulators that mishandled tabs. Eventually they got fixed (or I stopped using them). Long ago I used terminals where the tab stops were customizable, and the previous user had set them to weird values. At that time, I stopped using tabs. :-) Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
On 2007-01-18 17:39:40 +0100, Bruno Haible wrote: The --color option also has the effect of turning tabs into spaces; yet this is undocumented. Actually the doc states `ls' uses tabs where possible in the output, for efficiency. If COLS is zero, do not use tabs at all. and the phrase where possible is vague enough. It is not possible to use tabs with --color, and it is not possible to use tabs after non-ASCII characters. BTW, it shouldn't use tabs when the output does not correspond to a terminal. For instance, the user may want to send the file by mail or may want to indent it. Incorrect results can be obtained if there are tabs. A solution could be to have tabsize set to 0 by default. For users who need 8 (or some other value) because of a slow network (without compression, since a sequence of spaces should be compressed) could change its value. Vincent, do you have time to report that to the Apple people? No need to mention 'ls' - a simple printf 'E\xcc\x81\t2nd column\nFoo\t2nd column\n' should be all you need to demonstrate the bug. I'm not in such a good position to report it, since I'm using an older version of MacOS X. Done. FYI, the ID is 4940781 (but since the bug reports are not public, I doubt this ID is useful). However I have reported several bugs for more than a year, and none of them are fixed. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
On 2007-01-19 01:23:44 +0100, Bruno Haible wrote: Apple Terminal version 1.4.6, part of MacOS X 10.3.9, is affected. I forgot to say. This is still not fixed in Terminal 1.5 (133) from Mac OS X 10.4.8. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Savannah-hackers-public] Re: FYI: rm --interactive=never F no longer prompts for an unwritable F
On Thu, Jan 18, 2007 at 04:38:24PM +0100, Jim Meyering wrote: [EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: * tests/rm/i-never: New file. Test for the above fix. diff --git a/tests/rm/i-never b/tests/rm/i-never new file mode 100755 Unfortunately that did not make it into the CVS repository as mode 755 but instead is 644 there. Our old friend the mode problem on new test files has appeared again. Can you sync this up into the CVS repository? Hi Bob! Thanks for letting me know. I think this is because we're using too old a version of git-cvsexportcommit. I'll fix that, too. As far as I can see, we use 1.4.4.4 which is the latest released version (excluding release candidates ;)). Problem? -- Sylvain ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Pb avec aMule 2.1.3
Le Thu, 18 Jan 2007 09:53:55 +, Bidi Luciclo disait : Madame, monsieur, May you help me, cause I'm a very newbie with Linux...Thanks... HAPPY NEW YEAR ! 2007..and so on... Hello, 1. this is not the right place to post such a question because 2. the error comes from the fact that the 'install' command is not installed on your system. so you may post that question to a list dedicated to your system in order to know : 1. why the 'install' command is not installed on it (it should be I think) 2. How to manage (with your system) to install it. best regards, Olivier. -- translation in french : Salut, 1. ce n'est pas le bon endroit pour poster cette demande car : 2. l'erreur proviens du fait que tu n'as pas la commande install d'installée sur ton system. ainsi tu devrais poser ta question sur une liste de discussion dédiée a ton système afin de savoir : 1. pourquoi la commande install n'est pas présente (elle devrait l'être je pense) 2. comment on fait (avec ton système) pour l'installer Cordialement, Olivier :) [EMAIL PROTECTED] aMule-2.1.3]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking whether make sets $(MAKE)... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for bison... no checking for byacc... no checking for ranlib... (cached) ranlib checking for strip... strip checking for ar... ar checking for ld... ld checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for zlib = 1.1.4... yes (version 1.2.3) checking whether we need the GUI... yes checking for wx-config... /usr/bin/wx-config checking for wxWidgets version = 2.6.0... yes (version 2.6.3) checking for wxWidgets static library... no checking that wxWidgets has support for large files... yes checking whether to use embedded Crypto... yes checking for bfd headers... no configure: WARNING: bfd.h not found, please install binutils development package if you are a developer or want to help testing aMule checking for autopoint... ./configure: line 8223: autopoint: command not found no () configure: You need to install GNU gettext/gettext-tools to compile aMule with i18n support checking for extended flex capabilities... ./configure: line 8246: flex: command not found no configure: Your flex version doesn't support --header-file flag. This is not critical, but an upgrade is recommended checking for X... libraries , headers checking for working alloca.h... yes checking for alloca... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for ANSI C header files... (cached) yes checking argz.h usability... yes checking argz.h presence... yes checking for argz.h... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking for inttypes.h... (cached) yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking limits.h usability... yes checking limits.h presence... yes
I had a problem when i was Installing ddrescue and i think its a bug
I have been trying all day to install ddrescue and everytime from any download i get the same error message which in the terminal it says when i use sudo apt-get install make gcc g++ ddrescue it says this: [EMAIL PROTECTED]:~$ sudo apt-get install make gcc g++ ddrescue Reading package lists... Done Building dependency tree... Done make is already the newest version. E: Couldn't find package ddrescue Please help me i am desperate! Thanks, Jeff collins _ Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora. http://radio.msn.com ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: I had a problem when i was Installing ddrescue and i think its a bug
On Thursday 18 January 2007 16:23, Jeff Collins wrote: [EMAIL PROTECTED]:~$ sudo apt-get install make gcc g++ ddrescue while i feel bad that you're having troubles, none of this is related to the GNU coreutils package please send your question to a Debian users mailing list -mike pgpHKM1faYtLf.pgp Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: feature request: gzip/bzip support for sort
On Thu, Jan 18, 2007 at 05:47:53PM -0800, Dan Hipschman wrote: That's a thought, although libz only works with gzip (as you said), and it will add more complexity (like my original patch using LZO and this new one combined). I don't think we'll have 40 instances of gzip -d running. We should only need at most one compression process, and NMERGE (16) decompression processes running at one time. I think retrying fork if it fails is a good idea, and I've already added that since I read your mail. Apologies, I spoke to soon. We shouldn't have 40 *running* processes, but we generate a lot of defunct ones. I'm working on cleaning them up sooner and then hopefully we can bound the number of child processes at NMERGE + 1. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
