Re: tweaking default `ls -l` output to use locale before posix

[Paul Eggert]

Mike Frysinger <[EMAIL PROTECTED]> writes:

>> But before we go off the deep end here, why exactly is this change a
>> good idea?
>
> the idea is to make the default output as intuitive as possible ... imo, 
> defaulting to one's locale time format instead of a POSIX one makes more 
> sense ... but i wouldnt be suprised if others felt differently :)

Yes, it is a problem and quite possibly the right thing depends on the
locale and operating system.

I should emphasize again, though, that the current coreutils default
is not "a POSIX one" in the sense that you may be thinking.  The
coreutils default is an international format derived from ISO 8601.
This ISO-8601-derived format does conform to POSIX, but just about any
format would.  Even if you change coreutils so that
--time-style=locale is the default, coreutils is still defaulting to a
format that is "a POSIX one".


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

Re: Possible bug in sort utility

[Paul Eggert]

On 2005-08-12 "Tal V." <[EMAIL PROTECTED]> writes:

> When I sort a file by the second character in first field I have to
> refer to the second character as to character number "1" (command
> "sort 0.1 filename").

That can't be the syntax that you actually used.  Perhaps your email
client lopped off some characters?  You need to use a syntax like
"sort -k 1.2,1,2 filename".

> But when I want to sort a file by the second character in second (or higher)
> field I need to refer to the second character as to character number "2"
> (command "sort 1.2 filename").

Again, this can't be the syntax you were actually using.

In trying to decipher your email, my guess is that most likely you
need to use sort's -b option; you might try reading up on how it works
and why it's needed.


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

Re: tweaking default `ls -l` output to use locale before posix

[Mike Frysinger]

On Monday 26 September 2005 12:40 am, Paul Eggert wrote:
> Mike Frysinger <[EMAIL PROTECTED]> writes:
> > Gentoo has been using this patch too for
> > quite some time too ;)
>
> Debian doesn't have the patch, and I suspect other distributions don't
> either.  So we have a real split here.

RedHat/Fedora have been using it for quite sometime i think ... it's called 
'fileutils-4.1.10-timestyle.patch' in their rpms, and i believe it dates back 
to before the big fileutils/textutils/sh-utils merge into coreutils ...

> At the very least, Mandrake and Gentoo's patch should not look at
> POSIXLY_CORRECT, as this is not a POSIX-conformance issue.  If they
> want to change the default, they should simply replace

indeed ... i admit we just copied the patch straight from Mandrake and didnt 
fully investigate the POSIX aspects of it since as you pointed out, looking 
at the source quickly seems to imply that it is POSIX behavior to default to 
posix output style

> if (! (style = getenv ("TIME_STYLE")))
>   style = "posix-long-iso";
>
> with
>
> if (! (style = getenv ("TIME_STYLE")))
>   style = "locale";
>
> without looking at POSIXLY_CORRECT.  Could you please have this fixed
> in the source?  (I suspect it's easy for you to fix this with Gentoo
> at any rate)

yep, i'll fix it in Gentoo in the next day or so, thanks for the pointers

> One possibility is to make this all easier to configure without
> patching the source, e.g., with an
>
>#ifndef TIME_STYLE_DEFAULT
># define TIME_STYLE_DEFAULT "posix-long-iso"
>#endif
>...
>
> if (! (style = getenv ("TIME_STYLE")))
>   style = TIME_STYLE_DEFAULT;
>
> in the source code, and then let Mandrake and Gentoo configure with
> the appropriate CPPFLAGS.

just as easy to patch as to setup a CPPFLAG i think ...

> But before we go off the deep end here, why exactly is this change a
> good idea?

the idea is to make the default output as intuitive as possible ... imo, 
defaulting to one's locale time format instead of a POSIX one makes more 
sense ... but i wouldnt be suprised if others felt differently :)

> If it's just a personal preference, then the TIME_STYLE
> environment variable addresses the issue, no?  Perhaps Mandrake and/or
> Gentoo could simply set TIME_STYLE=locale in their users' standard
> startup files?

yes, that could be done, but one thing ive noticed working with Gentoo is that 
it's quite common for people to create new users 'by hand' ... that is, the 
skel dir isnt put into place quite as often as it should

also, going back to the intuitive behavior i mentioned previously, i generally 
try to push changes upstream so everyone benefits rather than just 
Gentoo/whoever ... thus i started bugging you guys
-mike


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

Re: tweaking default `ls -l` output to use locale before posix

[Paul Eggert]

Mike Frysinger <[EMAIL PROTECTED]> writes:

> Gentoo has been using this patch too for 
> quite some time too ;)

Debian doesn't have the patch, and I suspect other distributions don't
either.  So we have a real split here.

At the very least, Mandrake and Gentoo's patch should not look at
POSIXLY_CORRECT, as this is not a POSIX-conformance issue.  If they
want to change the default, they should simply replace

if (! (style = getenv ("TIME_STYLE")))
  style = "posix-long-iso";

with

if (! (style = getenv ("TIME_STYLE")))
  style = "locale";

without looking at POSIXLY_CORRECT.  Could you please have this fixed
in the source?  (I suspect it's easy for you to fix this with Gentoo
at any rate)


One possibility is to make this all easier to configure without
patching the source, e.g., with an

   #ifndef TIME_STYLE_DEFAULT
   # define TIME_STYLE_DEFAULT "posix-long-iso"
   #endif
   ...

if (! (style = getenv ("TIME_STYLE")))
  style = TIME_STYLE_DEFAULT;

in the source code, and then let Mandrake and Gentoo configure with
the appropriate CPPFLAGS.


But before we go off the deep end here, why exactly is this change a
good idea?  If it's just a personal preference, then the TIME_STYLE
environment variable addresses the issue, no?  Perhaps Mandrake and/or
Gentoo could simply set TIME_STYLE=locale in their users' standard
startup files?


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

Re: tweaking default `ls -l` output to use locale before posix

[Mike Frysinger]

On Sunday 25 September 2005 09:23 pm, Paul Eggert wrote:
> At any rate if other
> programs rely on the current behavior I'd be a bit leery about
> changing the default to --time-style=locale -- though if it works well
> for Mandrake that's an argument that it wouldn't hurt much to change
> it.

if it helps get this change accepted, Gentoo has been using this patch too for 
quite some time too ;)
-mike


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

Re: tweaking default `ls -l` output to use locale before posix

[Paul Eggert]

Mike Frysinger <[EMAIL PROTECTED]> writes:

> i was going through some patches Gentoo has for coreutils to figure out which 
> are outdated/pointless/etc... with 5.3.0 when i came across this patch from 
> Mandrake:
> --- src/ls.c
> +++ src/ls.c
> @@ -1612,5 +1612,7 @@
>  
>if (! style)
> if (! (style = getenv ("TIME_STYLE")))
> +   if (getenv ("POSIXLY_CORRECT"))
>   style = "posix-long-iso";
> + else style = "locale";
>  
>
> ignoring the broken formatting, i wonder if this change has been sent to the 
> list before for consideration (and i just couldnt find it in the archives) ? 

I don't recall seeing it, no.

> the idea seems OK to me; the `ls -l` default format follows the
> user's locale settings unless the env var POSIXLY_CORRET is set in
> which case we go with the standard 'posix-long-iso' format

I don't see why POSIXLY_CORRECT should affect the behavior here.
POSIXLY_CORRECT is intended for places where the GNU default is a
behavior that does not conform to POSIX, but the GNU default
(--time-style='posix-long-iso') does conform.

I suspect that Mandrake patch was put in by someone who wanted
--time-style='locale' to be the default, and thought that the only
reason --time-style='posix-long-iso' is the default is because POSIX
requires this.  But that's not the case: POSIX would allow either
time-style to be the default.

When I wrote that code back in 2002, I wanted posix-long-iso to be the
default for the benefit of Emacs.  Emacs's dired module parses dates,
but it misparses random dates generated in random locales (e.g., dates
based on the Japanese emperor's date of accession).  Having the
default be posix-long-iso avoided most of this problem.  I figured
other programs would have problems similar to Emacs.

If I recall correctly CVS Emacs now does this a different way and may
no longer need posix-long-iso to be the default, but the latest stable
Emacs still has the problem.  (My memory could be wrong, but someone
should check this before making changes.)  At any rate if other
programs rely on the current behavior I'd be a bit leery about
changing the default to --time-style=locale -- though if it works well
for Mandrake that's an argument that it wouldn't hurt much to change
it.


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

Re: CP Proposal - Benchmark + source code

[Paul Eggert]

>From the numbers you published in your email

it appears that the big win on your examples with 'cp' comes from
O_DIRECT, and that there's a mild improvement from O_STREAMING.

However, my understanding is that O_STREAMING is a dead end (see
)
and that they have merged posix_fadvise() into Linux 2.6.

Did you try POSIX_FADV_SEQUENTIAL as well?  It seems to me that
POSIX_FADV_NOREUSE | POSIX_FADV_SEQUENTIAL would be a closer POSIX
approximation to what "cp" needs than POSIX_FADV_NOREUSE by itself.

I don't understand why POSIX_FADV_NOREUSE | POSIX_FADV_SEQUENTIAL
would be so much worse than O_DIRECT, if they're properly implemented.
Perhaps you could elaborate?


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

Re: mv trailing slash warning

[Jim Meyering]

"Dr. David Alan Gilbert" <[EMAIL PROTECTED]> wrote:
>   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::.
> ---
...
> $ 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.

Losing systems probably deserve a configure-time test and a rename
wrapper to correct for the unexpected behavior.


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

mv trailing slash warning

[Dr. David Alan Gilbert]

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

coreutils test failure due to OOPS in amd64 linux-2.6.9: tmpfs-related

[Jim Meyering]

For the record, there seems to be a bug in amd64 linux-2.6.9 that
causes (soon-to-be-released) coreutils-5.3.1's tests/part-symlink
to fail with lots of segfaults (and kernel OOPSs) if the working
directory name is long enough.

I'm not planning to make the test work around it, since 2.6.9 is
pretty old for AMD64, and this isn't a problem with newer kernels.

The problem is that we get an OPPS when unlinking a symlink in
/dev/shm (tmpfs) when that symlink's value is 41 bytes or longer.

Here's a pared-down demo:

Unlinking a symlink with a 40-byte value works fine:
  $ ln -s $(printf %040d 0) /dev/shm/x; unlink /dev/shm/x

Unlinking a symlink with a 41-byte value causes the OOPS:
  $ ln -s $(printf %041d 0) /dev/shm/x; unlink /dev/shm/x
  Killed
  [Exit 137 (SIGKILL)]
  $
  Message from [EMAIL PROTECTED] at Sun Sep 25 05:12:42 2005 ...
   kernel: Oops:  [124] SMP

  Message from [EMAIL PROTECTED] at Sun Sep 25 05:12:42 2005 ...
   kernel: CR2: 0090

$ df -hT /dev/shm
FilesystemTypeSize  Used Avail Use% Mounted on
none tmpfs3.7G 0  3.7G   0% /dev/shm

$ uname -r
2.6.9-1.667smp


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

Re: gethostbyname on Solaris 5.7

[Simon Josefsson]

Jim Meyering <[EMAIL PROTECTED]> writes:

> Here's a log of a failed Solaris 5.7 build
>
>   cc  -I/usr/local/include  -R/usr/local/lib -L/usr/local/lib -o pinky  
> pinky.o ../lib/libcoreutils.a /usr/local/lib/libintl.so 
> /usr/local/lib/libiconv.so -lc -R/usr/local/lib ../lib/libcoreutils.a
>   Undefined   first referenced
>symbol in file
>   gethostbyname   ../lib/libcoreutils.a(getaddrinfo.o)
>   getservbyname   ../lib/libcoreutils.a(getaddrinfo.o)
>   ld: fatal: Symbol referencing errors. No output written to pinky
>   make[3]: *** [pinky] Error 1
>
> The problem was that coreutils no longer had the check for -lnsl.
> coreutils-5.3.0 had that test in canon-host.m4, and now that canon-host
> is just a wrapper around getaddrinfo, it's appropriate that it no longer
> perform this check.  So getaddrinfo.m4 must do it, now,
> and I've made the following change in coreutils, and
> will commit it to gnulib as soon as I've confirmed it works.

Hi!  Looks good, thanks!

> 2005-09-24  Jim Meyering  <[EMAIL PROTECTED]>
>
>   * getaddrinfo.m4 (gl_GETADDRINFO): Check for gethostbyname
>   in the inet and nsl libraries.  Required on Solaris 5.7.
>
> Index: m4/getaddrinfo.m4
> ===
> RCS file: /fetish/cu/m4/getaddrinfo.m4,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -p -u -r1.4 -r1.5
> --- m4/getaddrinfo.m4 23 Sep 2005 19:40:04 -  1.4
> +++ m4/getaddrinfo.m4 24 Sep 2005 10:44:30 -  1.5
> @@ -1,4 +1,4 @@
> -# getaddrinfo.m4 serial 4
> +# getaddrinfo.m4 serial 5
>  dnl Copyright (C) 2004, 2005 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -7,6 +7,7 @@ dnl with or without modifications, as lo
>  AC_DEFUN([gl_GETADDRINFO],
>  [
>AC_SEARCH_LIBS(getaddrinfo, nsl socket)
> +  AC_SEARCH_LIBS(gethostbyname, [inet nsl])
>AC_REPLACE_FUNCS(getaddrinfo gai_strerror)
>gl_PREREQ_GETADDRINFO
>  ])


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

Re: regex workaround for gcc 2.95.3 core dump

[Derek Price]

Paul,

This is the same problem I ran into a few days ago on several platforms,
and you helped me come up with this patch:
. 
The patch in that message also removes a little cruft and handles a
similar problem in a later GCC with always_inline, by ignoring
__attribute__ for GCC < 3.1.

Regards,

Derek


Paul Eggert wrote:

>I installed the following to work around a build failure of coreutils
>CVS on OpenBSD 3.4.  (For now I have resisted the temptation to enable
>__attribute__ only for GCC 4.0 and later.  :-)
>
>2005-09-24  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * regex_internal.h (__attribute): Define to nothing for GCC 2.
>   This works around a core dump on OpenBSD 3.4, which has GCC
>   2.95.3, which dumps core when given __attribute__(()).
>
>--- lib/regex_internal.h   23 Sep 2005 04:15:13 -  1.17
>+++ lib/regex_internal.h   24 Sep 2005 23:01:17 -  1.18
>@@ -131,7 +131,7 @@
> # define attribute_hidden
> #endif /* not _LIBC */
> 
>-#ifdef __GNUC__
>+#if __GNUC__ >= 3
> # define __attribute(arg) __attribute__ (arg)
> #else
> # define __attribute(arg)
>
>
>___
>bug-gnulib mailing list
>bug-gnulib@gnu.org
>http://lists.gnu.org/mailman/listinfo/bug-gnulib
>  
>


-- 
Derek R. Price
CVS Solutions Architect
Ximbiot 
v: +1 717.579.6168
f: +1 717.234.3125





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