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

[Nico Bdav]

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 "àçéèêëîïôöùüÂÇÉÈÊËÎÏÔÖÙÜ" "aciioouuACIIOOUU"
fUevrier


Steps to Reproduce:
1. Verify your locale for me it was LANG=fr_FR.UTF-8
2. Use tr as expected in the man page tr "àçéèêëîïôöùüÂÇÉÈÊËÎÏÔÖÙÜ"
"aciioouuACIIOOUU"
3.

Actual results:
 echo "février"  |  tr "àçéèêëîïôöùüÂÇÉÈÊËÎÏÔÖÙÜ" "aciioouuACIIOOUU"
fUevrier


Expected results:
 echo "février"  |  tr "àçéèêëîïôöùüÂÇÉÈÊËÎÏÔÖÙÜ" "aciioouuACIIOOUU"
fevrier

Here you will find bug-reports with screenshots:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183334
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120933

Greetings
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Join enhancements

[Paul Eggert]

"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 understand them from your brief
description.

Before we nail down the details, would you and your employer be
willing to assign the copyright to the Free Software Foundation, so
that we could install it in coreutils?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: dircolors test broken

[Jim Meyering]

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.
Here's the fix:

2006-03-03  Jim Meyering  <[EMAIL PROTECTED]>

Don't fail when run from an environment with SHELL not a Bourne
shell, e.g. `env SHELL=/bin/csh make check' would fail this test.
* tests/dircolors/simple: Invoke each non-failing test with -b.
Reported by Michael Stone.

Index: tests/dircolors/simple
===
RCS file: /fetish/cu/tests/dircolors/simple,v
retrieving revision 1.8
retrieving revision 1.10
diff -u -p -r1.8 -r1.10
--- tests/dircolors/simple  25 Oct 2005 12:00:51 -  1.8
+++ tests/dircolors/simple  3 Mar 2006 07:49:39 -   1.10
@@ -23,11 +23,14 @@ my @Tests =
  ['a', {IN => {k => "exec\n"}},
   {ERR => "dircolors: k:1: invalid line;  missing second token\n"},
   {EXIT => 1}],
- ['quote', {IN => "exec 'echo Hello;:'\n"},
+ ['quote', '-b', {IN => "exec 'echo Hello;:'\n"},
   {OUT => "LS_COLORS='ex='\\''echo Hello;\\:'\\'':';\n"
   . "export LS_COLORS\n"}],
- ['other-wr', {IN => "owt 40;33\n"},
+ ['other-wr', '-b', {IN => "owt 40;33\n"},
   {OUT => "LS_COLORS='tw=40;33:';\nexport LS_COLORS\n"}],
+
+ # CAREFUL: always specify the -b option, unless explicitly testing
+ # for csh syntax output.
 );
 
 my $save_temps = $ENV{DEBUG};


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: make error

[Paul Eggert]

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 directory `/cygdrive/c/icu/source/stubdata'

I don't see the connection between this and coreutils; perhaps you
should be asking on a Cygwin mailing list rather than on
bug-coreutils?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[anonymous]

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
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open

___

Details:

Coreutils do not build with gcc 4.0.2 because of changes to the "restrict"
keyword. The build must pass -std=iso9899:199x to the compiler.






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: make error

[Brian Dessent]

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 `/cygdrive/c/icu/source/stubdata'
> 
> I don't see the connection between this and coreutils; perhaps you
> should be asking on a Cygwin mailing list rather than on
> bug-coreutils?

It seems like he's using some kind of Makefile that expects to call
LINK.EXE (the Microsoft linker) to do linking, but instead it is trying
to invoke /bin/link from coreutils.  In that case it's a problem with
his Makefile and/or his PATH and/or his environment, but has nothing to
do with Cygwin or coreutils.

Brian


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Paul Eggert]

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 GCC 4.0.2 myself. I am attaching the
build log; please compare it to yours, and see what's
different about your environment.

___

Additional Item Attachment:

File name: log.txtSize:192 KB
log of successful build of coreutils 5.94 with GCC 4.0.2


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: root-dev-ino.c limitation

[Jim Meyering]

[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 it was surprisingly easier than
> I feared, and also uncovered a real bug in pwd.c (file_name_prepend
> already adds /, so when your current directory is "/", pwd
> was printing "//").

Thanks, this does look good.
Would you please keep the bug-fix separate, and include
a test for it, if possible?

Why do you want to merge this change with the
already-big basename/dirname one?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ls -i inefficiency

[Paul Eggert]

[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  savsmtptemp
   56-pete $ /usr/xpg4/bin/ls -L
   eggert.kshh  foo  savsmtptemp

OpenBSD 3.4 ls is similar.  So I guess your fix has _removed_ an
incompatibility rather than added one.  Good show!

> I just reread the POSIX wording

So did I.  It is a bit muddy.  I think we can do whatever we want
here, and I don't see a strong reason to do it one way or the other so
I prefer being compatible with the other guys.

I'd write up a NEWS item but I'm not sure when the GNU ls behavior
changed.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: ls -i inefficiency

[Paul Eggert]

[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 it is a directory.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: base64 tool?

[Jim Meyering]

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 within 80 columns.

* tests/misc/Makefile.am (TESTS): Add base64.
* tests/misc/base64: Test base64.  From Simon Josefsson.

* src/base64.c (do_decode): Use correct type for parameter,
ignore_garbage: s/size_t/bool/.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

report

[ojola odeny]

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.
Use --sparse=never to inhibit creation of sparse files.
  The backup suffix is `~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:
none, off   never make backups (even if --backup is given)
  numbered, t make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups
  As a special case, cp makes a backup of SOURCE when the force and backup
options are given and SOURCE and DEST are the same name for an existing,
regular file.
  Report bugs to .
   
  I dont understand this can you help me go about it. My work is not ok


-
Relax. Yahoo! Mail virus scanning helps detect nasty viruses!
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Dan Jacobson]

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 /mnt/usb/pqi
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda115968  9072  6896  57% /mnt/usb/pqi
# sync
# 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 
# mkdir /mnt/usb/pqi/dir
# cp xutils_6.9.0.dfsg.1-4_i386.deb /mnt/usb/pqi/dir
#

Well if the problem is that the flash card's root FAT file table was
full, then there should be a better message!

Separate "directory full" from "disk full" when giving messages to the
user, else he might never guess the solution.

Maybe historically for UNIX this would never happen, so the messages
were never improved.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sort -u -n error : sort v 4.5.3

[Will Smith]

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 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





Workaround: run sort twice, once with each parameter.


[EMAIL PROTECTED] data]# sort -u < /tmp/new_spammers | sort -n
64.202.165.131
64.202.165.132
64.202.165.133




Regards,

--
Will Smith
Web   : www.willsmith.org
Email : www.willsmith.org/contactme.php







___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

module for PRI*MAX macros?

[Eric Blake]

-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
guarantee (long long) and %lld.  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 using:

ino_t ino = ...;
printf("inode %" PRIuMAX "\n", (uintmax_t) ino);

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFECiGA84KuGfSFAYARAiioAJ9D8F/aQxbyyo8+tu2mYkTfnu/MAgCdHLl4
ZooZOch9BdcGDc6E5RAHSJU=
=wJoR
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Andreas Schwab]

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_spammers
> 64.202.165.132

Not a bug: all three lines have the same sort key, namely the number
64.202, the rest of the sort field is ignored.  You probably want to split
the line on the period and treat each whole number as a separate sort key:

$ sort -t. -u -n -k1,1 -k2,2 -k3,3 -k4,4 < /tmp/new_spammers

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Eric Blake]

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.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 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/009695399/utilities/sort.html,
which states that -n restricts the key to the first numeric
field, and that -u uniquifies based on the sort key.

In your sample file, the unique key is 64, and all
three lines have the same key.  When -n or -u is
used alone, a tiebreaker is used that sorts based
on the rest of the line.  But when used together,
the behavior correctly stops after one line.

-- 
Eric Blake


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Eric Blake]

> > [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/009695399/utilities/sort.html,
> which states that -n restricts the key to the first numeric
> field, and that -u uniquifies based on the sort key.
> 
> In your sample file, the unique key is 64, and all
> three lines have the same key.  When -n or -u is
> used alone, a tiebreaker is used that sorts based
> on the rest of the line.  But when used together,
> the behavior correctly stops after one line.

However, I think this does point out some bugs in POSIX
compliance - GNU sort currently parses the decimal separator
in a numeric sort key, whereas POSIX does not permit that; and
treats signed zeros as significant, where POSIX does not
permit that:

   sort 5.94:
$ export LANG=C LC_ALL=C POSIXLY_CORRECT=1
$ cat blah
64.202
64.201
64.203
0
-0
0
$ sort -n blah
-0
0
0
64.201
64.202
64.203
$ sort -nu blah
0
64.201
64.202
64.203

  POSIX:
$ sort -n blah  # lines with equal numeric keys should stay stable during sort
0
-0
0
64.202
64.201
64.203
$ sort -nu blah # numeric keys do not include decimal points in LANG=C
0
64.202

-- 
Eric Blake


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: module for PRI*MAX macros?

[Paul Eggert]

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 module, just as there now is a stdint
module.  It might take some work to get it right, though.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils