"tr" doesn't seems to be locale sensitive (UTF-8 problem)

Description of problem: Using tr to translate accentuated characters to simple characters. Version-Release number of selected component (if applicable): rpm -qf /usr/bin/tr coreutils-5.2.1-48.1 How reproducible: Everytime using tr with $LANG=fr_FR.UTF-8 echo "février" | tr "àçéèêëîïôöùüÂÇÉÈÊË

Re: Join enhancements

"David G. Pickett" <[EMAIL PROTECTED]> writes: > I think we might extend the gnu join in a backwards compatible way > to have this flavor of capabilities, and make the it much more > useful. It sounds like you have a useful set of extensions to GNU join, though I admit I don't completely understa

Re: dircolors test broken

Michael Stone <[EMAIL PROTECTED]> wrote: > The "simple" dircolors test seems to assume that the controlling shell > isn't csh. I don't grok the test syntax to make a patch, but this should > be as simple as running "env SHELL=sh dircolors" instead of just > "dircolors". Thanks for reporting that.

Re: make error

Robert Tellamalla <[EMAIL PROTECTED]> writes: > LINK.EXE /subsystem:console /DLL /nologo /base:"0x4ad0" /NOENTRY > /IMPLIB:ic > udt.lib /out:icudt34.dll stubdata.o > LINK: extra operand `/nologo' > Try `LINK --help' for more information. > make[1]: *** [icudt34.dll] Error 1 > make[1]: Leaving

[bug #15971] Coreutils 5.94 need to build with -std=iso9899:199x with gcc 4.0.2

URL: Summary: Coreutils 5.94 need to build with -std=iso9899:199x with gcc 4.0.2 Project: GNU Core Utilities Submitted by: None Submitted on: Fri 03/03/06 at 11:49

Re: make error

Paul Eggert wrote: > > LINK.EXE /subsystem:console /DLL /nologo /base:"0x4ad0" /NOENTRY > > /IMPLIB:ic > > udt.lib /out:icudt34.dll stubdata.o > > LINK: extra operand `/nologo' > > Try `LINK --help' for more information. > > make[1]: *** [icudt34.dll] Error 1 > > make[1]: Leaving directory `/

[bug #15971] Coreutils 5.94 need to build with -std=iso9899:199x with gcc 4.0.2

Update of bug #15971 (project coreutils): Status:None => Need Info ___ Follow-up Comment #1: I don't observe this problem on my Debian GNU/Linux stable host, in which I have installed GC

Re: root-dev-ino.c limitation

[EMAIL PROTECTED] (Eric Blake) wrote: ... > I've already done a first cut at the edits, attached for review. > Obviously, I will need to clean up where > DOUBLE_SLASH_IS_DISTINCT_ROOT gets defined, and merge > this patch in with my outstanding basename/dirname patch > before it can be applied. But

Re: ls -i inefficiency

[EMAIL PROTECTED] (Eric Blake) writes: > What does Solaris 10 do? Good point. My Solaris 10 host is down right now, but Solaris 9 does not complain: 54-pete $ ls -l foo lrwxrwxrwx 1 eggert eggert 7 Feb 26 15:22 foo -> nowhere 55-pete $ /bin/ls -L eggert.kshh foo

Re: ls -i inefficiency

[EMAIL PROTECTED] (Eric Blake) writes: > So do OpenBSD and Solaris warn when -L appears with an > explicit listing of a broken link? Solaris does. (Dunno about OpenBSD.) The distinction, I think, is partly that "ls -L" merely reads ".", whereas "ls -L foo" must dereference "foo" to see whether

Re: base64 tool?

Simon Josefsson <[EMAIL PROTECTED]> wrote: > Here are updated tests. They test several corner cases, but still not > comprehensive. Thank you! Applied. 2006-02-27 Jim Meyering <[EMAIL PROTECTED]> * tests/misc/base64: Factor out a long constant string. Split lines to stay withi

report

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made sparse as well. That is the behavior selected by --sparse=auto. Specify --sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes. Us

Bug#354875: /bin/cp directory full vs. disk full messages

Package: coreutils Version: 5.93-5 Severity: normal File: /bin/cp Trying to copy a less than 1MB file to a half full 16MB flash card, I get: # cp xutils_6.9.0.dfsg.1-4_i386.deb /mnt/usb/pqi cp: cannot create regular file `/mnt/usb/pqi/xutils_6.9.0.dfsg.1-4_i386.deb': No space left on device # df

sort -u -n error : sort v 4.5.3

Sort : the -u (unique) and -n (numeric) options seem to clash, removing too many lines. [EMAIL PROTECTED] data]# cat /tmp/new_spammers 64.202.165.132 64.202.165.131 64.202.165.133 [EMAIL PROTECTED] data]# sort -u < /tmp/new_spammers 64.202.165.131 64.202.165.132 64.202.165.133 [ [EMAIL PROT

module for PRI*MAX macros?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I recently reported a findutils bug (https://savannah.gnu.org/bugs/?func=detailitem&item_id=15472) where an error message on cygwin was truncating ino_t (64 bits) because it was using %ld (32 bits). But James correctly reminded me that C89 does not gu

Re: sort -u -n error : sort v 4.5.3

Will Smith <[EMAIL PROTECTED]> writes: > Sort : the -u (unique) and -n (numeric) options seem to clash, removing too > many lines. > > > [EMAIL PROTECTED] data]# cat /tmp/new_spammers > 64.202.165.132 > 64.202.165.131 > 64.202.165.133 [...] > [EMAIL PROTECTED] data]# sort -u -n < /tmp/new_spamme

Re: sort -u -n error : sort v 4.5.3

The most recent stable version of coreutils is 5.94; consider upgrading (although that does not change your report). > Sort : the -u (unique) and -n (numeric) options seem to clash, removing too > many lines. > > > [EMAIL PROTECTED] data]# cat /tmp/new_spammers > 64.202.165.132 > 64.202.165.13

Re: sort -u -n error : sort v 4.5.3

> > [EMAIL PROTECTED] data]# sort -n < /tmp/new_spammers > > 64.202.165.131 > > 64.202.165.132 > > 64.202.165.133 > > > > > > [EMAIL PROTECTED] data]# sort -u -n < /tmp/new_spammers > > 64.202.165.132 > > Not a bug. This behavior is required by POSIX, > http://www.opengroup.org/onlinepubs/00969

Re: module for PRI*MAX macros?

Eric Blake <[EMAIL PROTECTED]> writes: > Is it time to make a gnulib module that exposes what is currently > done in coreutils' src/system.h to provide PRIuMAX and friends on > systems that lack them, so that it becomes possible to portably > print an ino_t value Ideally there'd be an inttypes mo