Re: coreutils-6.3 on MacOS X

[Bruno Haible]

Paul Eggert wrote:
> > at-func.c:39: warning: implicit declaration of function `lchown'
> > dirchownmod.c:102: warning: implicit declaration of function `lchown'
> > (lchown is not provided by the system; gnulib's substitute is used.)
> > mkstemp-safer.c:34: warning: implicit declaration of function `mkstemp'
> 
> Thanks for reporting these.  I installed the following in an
> attempt to fix them.

The warnings are indeed gone. coreutils CVS as of Saturday behaves as follows 
on MacOS X 10.3.9:

if gcc -std=gnu99  -I. -I. -I.   -Wall -I/Volumes/UserData/local-macos/include  
 -g -O2 -MT lchown.o -MD -MP -MF ".deps/lchown.Tpo" -c -o lchown.o lchown.c; \
then mv -f ".deps/lchown.Tpo" ".deps/lchown.Po"; else rm -f ".deps/lchown.Tpo"; 
exit 1; fi
In file included from lchown.c:26:
stat-macros.h:26:4: #error "you must include  before including this 
file"
lchown.c: In function `lchown':
lchown.c:37: error: storage size of `stats' isn't known
lchown.c:39: warning: implicit declaration of function `lstat'
lchown.c:37: warning: unused variable `stats'
make[2]: *** [lchown.o] Error 1

This fixes it:

diff -r -c3 coreutils-6.3a/lib/lchown.c 
/gfs/ibook/Volumes/UserData/work/coreutils-6.3a/lib/lchown.c
*** coreutils-6.3a/lib/lchown.c 2006-10-07 01:01:48.0 +0200
--- /gfs/ibook/Volumes/UserData/work/coreutils-6.3a/lib/lchown.c
2006-10-08 01:53:15.0 +0200
***
*** 23,28 
--- 23,29 
  
  #include "lchown.h"
  
+ #include 
  #include "stat-macros.h"
  
  /* Work just like chown, except when FILE is a symbolic link.


Then, later:

pathchk.c:203: warning: missing braces around initializer
pathchk.c:203: warning: (near initialization for `mbstate.__mbstate8')

Here the problem is:
  mbstate_t mbstate = {0};
ISO C 99 guarantees only that mbstate_t is not an array type; it could
be a scalar or pointer type. The fix is therefore to use an initialization
through memset, as in mbswidth.c and quotearg.c.

diff -r -c3 coreutils-6.3a/src/pathchk.c 
/gfs/ibook/Volumes/UserData/work/coreutils-6.3a/src/pathchk.c
*** coreutils-6.3a/src/pathchk.c2006-04-29 18:17:53.0 +0200
--- /gfs/ibook/Volumes/UserData/work/coreutils-6.3a/src/pathchk.c   
2006-10-08 02:07:15.0 +0200
***
*** 1,5 
  /* pathchk -- check whether file names are valid or portable
!Copyright (C) 1991-2005 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
--- 1,5 
  /* pathchk -- check whether file names are valid or portable
!Copyright (C) 1991-2006 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
***
*** 200,207 
  
if (*invalid)
  {
!   mbstate_t mbstate = {0};
!   size_t charlen = mbrlen (invalid, filelen - validlen, &mbstate);
error (0, 0,
 _("nonportable character %s in file name %s"),
 quotearg_n_style_mem (1, locale_quoting_style, invalid,
--- 200,210 
  
if (*invalid)
  {
!   mbstate_t mbstate;
!   size_t charlen;
! 
!   memset (&mbstate, 0, sizeof mbstate);
!   charlen = mbrlen (invalid, filelen - validlen, &mbstate);
error (0, 0,
 _("nonportable character %s in file name %s"),
 quotearg_n_style_mem (1, locale_quoting_style, invalid,


All "make check" tests pass. Congratulations!

Bruno


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

coreutils CVS on NetBSD 3.0

[Bruno Haible]

Hi,

The testing results of coreutils CVS as of Saturday, on NetBSD 3.0:

if gcc -std=gnu99  -I. -I. -I.-Wall -I/home/bruno/gnu/include   -g -O2 -MT 
filemode.o -MD -MP -MF ".deps/filemode.Tpo" -c -o filemode.o filemode.c;  then 
mv -f ".deps/filemode.Tpo" ".deps/filemode.Po"; else rm -f 
".deps/filemode.Tpo"; exit 1; fi
filemode.c: In function `filemodestring':
filemode.c:171: warning: implicit declaration of function `strmode'

Since strmode() is declared in , the following fixes it:

*** coreutils-6.3a/lib/filemode.c.bak   2006-09-19 00:51:16.0 +0200
--- coreutils-6.3a/lib/filemode.c   2006-10-08 16:35:12.0 +0200
***
*** 21,26 
--- 21,27 
  
  #include "filemode.h"
  
+ #include 
  #include "stat-macros.h"
  
  /* The following is for Cray DMF (Data Migration Facility), which is a

All tests pass.

Bruno


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

Re: coreutils-6.3 on Linux 2.4 kernel

[Bruno Haible]

Paul Eggert wrote:
> However, I can't test this easily since I don't have such a kernel.
> ...
> It's not an ideal fix, but it's the best I could
> think of offhand.

Thanks! coreutils + gnulib from Saturday now pass "make check" entirely
fine on the Linux-2.4.21 machine.

Bruno



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

Re: coreutils-6.3 on MacOS X

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> pathchk.c:203: warning: missing braces around initializer
> pathchk.c:203: warning: (near initialization for `mbstate.__mbstate8')
>
> Here the problem is:
>   mbstate_t mbstate = {0};
> ISO C 99 guarantees only that mbstate_t is not an array type; it could
> be a scalar or pointer type. The fix is therefore to use an initialization
> through memset, as in mbswidth.c and quotearg.c.

Thanks again.
Applied:

2006-10-09  Jim Meyering  <[EMAIL PROTECTED]>

Avoid a compiler warning.
* src/pathchk.c (portable_chars_only): Initialize variable of type
mbstate_t via memset, rather than via '{0}'.  Patch from Bruno Haible.

Index: src/pathchk.c
===
RCS file: /fetish/cu/src/pathchk.c,v
retrieving revision 1.88
diff -u -r1.88 pathchk.c
--- src/pathchk.c   30 May 2005 07:05:07 -  1.88
+++ src/pathchk.c   9 Oct 2006 11:52:26 -
@@ -1,5 +1,5 @@
 /* pathchk -- check whether file names are valid or portable
-   Copyright (C) 1991-2005 Free Software Foundation, Inc.
+   Copyright (C) 1991-2006 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
@@ -200,8 +200,11 @@

   if (*invalid)
 {
-  mbstate_t mbstate = {0};
-  size_t charlen = mbrlen (invalid, filelen - validlen, &mbstate);
+  mbstate_t mbstate;
+  size_t charlen;
+
+  memset (&mbstate, 0, sizeof mbstate);
+  charlen = mbrlen (invalid, filelen - validlen, &mbstate);
   error (0, 0,
 _("nonportable character %s in file name %s"),
 quotearg_n_style_mem (1, locale_quoting_style, invalid,


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

Re: coreutils-6.3 on MacOS X

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
...
> In file included from lchown.c:26:
> stat-macros.h:26:4: #error "you must include  before including 
> this file"
> lchown.c: In function `lchown':
> lchown.c:37: error: storage size of `stats' isn't known
> lchown.c:39: warning: implicit declaration of function `lstat'
> lchown.c:37: warning: unused variable `stats'
> make[2]: *** [lchown.o] Error 1
>
> This fixes it:
>
> diff -r -c3 coreutils-6.3a/lib/lchown.c 
> /gfs/ibook/Volumes/UserData/work/coreutils-6.3a/lib/lchown.c
...
> + #include 
>   #include "stat-macros.h"

Thanks.
I've checked in that change:

2006-10-09  Jim Meyering  <[EMAIL PROTECTED]>

* lchown.c: Include  before "stat-macros.h".
Patch from Bruno Haible.


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

Re: coreutils-6.3 on MacOS X

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 10/9/2006 5:50 AM:
> Thanks.
> I've checked in that change:
> 
> 2006-10-09  Jim Meyering  <[EMAIL PROTECTED]>
> 
>   * lchown.c: Include  before "stat-macros.h".
>   Patch from Bruno Haible.

Why not instead fix stat-macros.h to include ?  Then future
users of "stat-macros.h" don't have to worry about this portability trap.

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

iD8DBQFFKkDD84KuGfSFAYARAlGFAJ90oEIc8uCWnd0oqc/IsT8GFLQhLgCdHhB2
FpXL95V1D3SPv1mapNrvHgs=
=B8mQ
-END PGP SIGNATURE-


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

symlink calculation in bootstrap script

[Bruno Haible]

Hi,

Here's a patch to lift a few restrictions in the bootstrap script.


2006-10-08  Bruno Haible  <[EMAIL PROTECTED]>

* bootstrap (func_relativize): New function, taken from gnulib-tool.
(symlink_to_gnulib): Use it.

*** bootstrap.bak   2006-10-07 15:40:13.0 +0200
--- bootstrap   2006-10-08 14:14:24.0 +0200
***
*** 245,267 
fi;;
  esac
  
  symlink_to_gnulib()
  {
src=$GNULIB_SRCDIR/$1
dst=${2-$1}
-   dot_dots=
- 
case $src in
!   /*) ;;
*)
! case /$dst/ in
! *//* | */../* | */./* | /*/*/*/*/*/)
!echo >&2 "$0: invalid symlink calculation: $src -> $dst"
!exit 1;;
! /*/*/*/*/)dot_dots=../../../;;
! /*/*/*/)  dot_dots=../../;;
! /*/*/)dot_dots=../;;
! esac;;
esac
  
test -f "$src" && {
--- 251,304 
fi;;
  esac
  
+ # func_relativize DIR1 DIR2
+ # computes a relative pathname RELDIR such that DIR1/RELDIR = DIR2.
+ # Input:
+ # - DIR1relative pathname, relative to the current directory
+ # - DIR2relative pathname, relative to the current directory
+ # Output:
+ # - reldir  relative pathname of DIR2, relative to DIR1
+ func_relativize ()
+ {
+   dir0=`pwd`
+   dir1="$1"
+   dir2="$2"
+   sed_first='s,^\([^/]*\)/.*$,\1,'
+   sed_rest='s,^[^/]*/*,,'
+   sed_last='s,^.*/\([^/]*\)$,\1,'
+   sed_butlast='s,/*[^/]*$,,'
+   while test -n "$dir1"; do
+ first=`echo "$dir1" | sed -e "$sed_first"`
+ if test "$first" != "."; then
+   if test "$first" = ".."; then
+ dir2=`echo "$dir0" | sed -e "$sed_last"`/"$dir2"
+ dir0=`echo "$dir0" | sed -e "$sed_butlast"`
+   else
+ first2=`echo "$dir2" | sed -e "$sed_first"`
+ if test "$first2" = "$first"; then
+   dir2=`echo "$dir2" | sed -e "$sed_rest"`
+ else
+   dir2="../$dir2"
+ fi
+ dir0="$dir0"/"$first"
+   fi
+ fi
+ dir1=`echo "$dir1" | sed -e "$sed_rest"`
+   done
+   reldir="$dir2"
+ }
+ 
  symlink_to_gnulib()
  {
src=$GNULIB_SRCDIR/$1
dst=${2-$1}
case $src in
!   /*) reldir=$src;;
*)
! case $dst in
! /*) reldir=$src;;
! *) func_relativize "$dst" "$src";;
! esac
esac
  
test -f "$src" && {
***
*** 269,276 
  src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
  dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
  test "$src_i" = "$dst_i" || {
!   echo "$0: ln -fs $dot_dots$src $dst" &&
!   ln -fs "$dot_dots$src" "$dst"
  }
}
  }
--- 306,313 
  src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
  dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
  test "$src_i" = "$dst_i" || {
!   echo "$0: ln -fs $reldir $dst" &&
!   ln -fs "$reldir" "$dst"
  }
}
  }


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

make it possible to avoid symlinks in coreutils' bootstrap

[Bruno Haible]

Hi Paul,

The fact that coreutils' bootstrap script creates symlinks can be an
annoyance:
  - Creating self-contained tarballs requires extra effort.
  - On my systems, I have a date as part of the gnulib directory name,
and rename it each time I update. In such a situation, the symlinks
break often.

Would you mind adding a --copy option to the bootstrap script? Roughly
like this?

Bruno


*** bootstrap.bak   2006-10-08 14:18:02.0 +0200
--- bootstrap   2006-10-08 14:21:50.0 +0200
***
*** 40,45 
--- 40,46 
have gnulib sources on your machine, and
do not want to waste your bandwidth dowloading
them again.
+  --copy   Copy files instead of creating symbolic links.
   --force  Bootstrap even if the sources didn't come from CVS.
   --skip-poDo not download po files.
   --cvs-user=USERNAME  Set the CVS username to be used when accessing
***
*** 112,117 
--- 113,121 
  # the distributed version.
  CVS_only_file=CVS
  
+ # Whether to try symlinks before attempting a plain copy.
+ try_ln_s=:
+ 
  # Override the default configuration, if necessary.
  test -r bootstrap.conf && . ./bootstrap.conf
  
***
*** 133,138 
--- 137,144 
  SKIP_PO=t;;
--force)
  CVS_only_file=;;
+   --copy)
+ try_ln_s=false;;
*)
  echo >&2 "$0: $option: unknown option"
  exit 1;;
***
*** 300,307 
  src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
  dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
  test "$src_i" = "$dst_i" || {
!   echo "$0: ln -fs $reldir $dst" &&
!   ln -fs "$reldir" "$dst"
  }
}
  }
--- 306,318 
  src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
  dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
  test "$src_i" = "$dst_i" || {
!   ( $try_ln_s &&
! ln -fs "$reldir" "$dst" &&
! echo "$0: ln -fs $reldir $dst"
!   ) 2>/dev/null ||
!   { echo "$0: cp -f $src $dst"
! cp -f "$src" "$dst"
!   }
  }
}
  }


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

Re: coreutils-6.3 on MacOS X

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 10/9/2006 5:50 AM:
>> Thanks.
>> I've checked in that change:
>>
>> 2006-10-09  Jim Meyering  <[EMAIL PROTECTED]>
>>
>>  * lchown.c: Include  before "stat-macros.h".
>>  Patch from Bruno Haible.
>
> Why not instead fix stat-macros.h to include ?  Then future
> users of "stat-macros.h" don't have to worry about this portability trap.

Because there have been problems with systems for which 
cannot be included more than once.

Maybe it's time to reexamine that restriction, but I'm in no hurry.


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

Re: coreutils-6.3 on MacOS X

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 10/9/2006 6:40 AM:
>> Why not instead fix stat-macros.h to include ?  Then future
>> users of "stat-macros.h" don't have to worry about this portability trap.
> 
> Because there have been problems with systems for which 
> cannot be included more than once.

Then it sounds like we should provide a  replacement, just as
we do for  and others.

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

iD8DBQFFKkd384KuGfSFAYARAt5uAJ98OpPV+AV2VCKP82mJVXQy0qBd2QCfWeeP
08otGYhQA+vvr56Jv3mgDow=
=ykml
-END PGP SIGNATURE-


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

Re: coreutils-6.3 on MacOS X

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 10/9/2006 6:40 AM:
>>> Why not instead fix stat-macros.h to include ?  Then future
>>> users of "stat-macros.h" don't have to worry about this portability trap.
>>
>> Because there have been problems with systems for which 
>> cannot be included more than once.
>
> Then it sounds like we should provide a  replacement, just as
> we do for  and others.

Yep.  Did you just volunteer?  :-)
 had similar problems.
That's why coreutils/src/system.h does this:

/* Include sys/types.h before this file.  */

#if 2 <= __GLIBC__ && 2 <= __GLIBC_MINOR__
# if ! defined _SYS_TYPES_H
you must include  before including this file
# endif
#endif


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

Re: [bug #17908] 'configure' fails because it is unable to determine how to read the mount table.

[mwoehlke]

Jim Meyering wrote:

Update of bug #17908 (project coreutils):
Severity:  3 - Normal => 2 - Minor  
___


Follow-up Comment #3:

Thanks for the report.  Considering the affected systems are not mainstream,
I'm changing severity to "minor".


Fine with me, since I can't *change* the severity. :-)
Thanks...

--
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)



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

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:

source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \
DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \
cc -std  -I. -I. -I.   -I/home/install/gnu/alpha_osf/include -g -c 
xstrtoimax.c
cc: Warning: ./config.h, line 1741: The redefinition of the macro
"intmax_t" conflicts with a current definition because the replacement
lists differ.  The redefinition is now in effect. (macroredef)
#define intmax_t long long
-^


I think I see the problem now; you can't include , then
, then , due to  having some
semi-obsolescent definitions of intmax_t (due to gettext not yet
upgrading to assume inttypes.h).

I installed this into gnulib to fix things:

[patch snipped]


Sounds good, thanks!

--
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)



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

[date] ISO-8601 date format

[JL Lacroix]

Hello,

To convert a date into the full ISO-8601 format one can do this:

 $ date --iso-8601=seconds --date "sun oct 1 5:45:02PM"

It will correctly returns:

 2006-10-01T17:45:02+0200

But when we want to convert a ISO-8601 formated date into a man readable format:

 $ date --date "2006-10-01T17:45:02"
Returns:
 Sun Oct  1 12:45:02 CEST 2006

 $ date --date "2006-10-01T17:45:02+0200"
Returns
 date: invalid date `2006-10-01T17:45:02+0200'

Obviously, the full ISO-8601 format is not accepted as date input format.

Any work around?

date --version --> (coreutils) 5.2.1


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

Re: [date] ISO-8601 date format

[Andreas Schwab]

"JL Lacroix" <[EMAIL PROTECTED]> writes:

>  $ date --date "2006-10-01T17:45:02+0200"
> Returns
>  date: invalid date `2006-10-01T17:45:02+0200'
>
> Obviously, the full ISO-8601 format is not accepted as date input format.
>
> Any work around?

Replace the T with a space.

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: [date] ISO-8601 date format

[Bob Proulx]

JL Lacroix wrote:
> To convert a date into the full ISO-8601 format one can do this:
> 
>  $ date --iso-8601=seconds --date "sun oct 1 5:45:02PM"

The NEWS for the latest CVS says:

  date accepts the new option --rfc-3339=TIMESPEC.  The old --iso-8602 (-I)
  option is deprecated; it still works, but new applications should avoid it.
  date, du, ls, and pr's time formats now support new %:z, %::z, %:::z
  specifiers for numeric time zone offsets like -07:00, -07:00:00, and -07.

So once you get updated to a 6.x release (>= 5.90 actually) then you
can start using the new --rfc-3339 option.

Paul, Shouldn't that be iso-8601 instead of iso-8602 in the above?

> But when we want to convert a ISO-8601 formated date into a man readable 
> format:
> ...
> Obviously, the full ISO-8601 format is not accepted as date input format.

Basically fixed by the --rfc-3339 option for which you will need to
upgrade to a 6.x release.  Until then you will need to process the
date format and reformat it before passing it back to date.

You may find this discussion useful.

  http://lists.gnu.org/archive/html/bug-coreutils/2005-05/msg00098.html

Particularly this posting:

  http://lists.gnu.org/archive/html/bug-coreutils/2005-07/msg00186.html

Bob


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

Re: make check "failure" on Itanium HPUX

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:


You mean /usr/bin/posix, right?


Yes.


 14388 Segmentation fault  (core dumped) | diff - $t

So it looks like 'diff' is broken?


I guess so.  But that's a different issue.  Try removing the broken
diff and using the system-standard diff.  You can debug diff later.


Ok, confirming that diff is broken; 'make check' passed with 
/usr/bin/diff. Looks like I'll be (hopefully) filing a bug against 
diffutils.


--
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)



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

[bug #17956] "sort" manual should mention that fields are numbered starting from 1

[anonymous]

URL:
  

 Summary: "sort" manual should mention that fields are
numbered starting from 1
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Monday 10/09/2006 at 18:33 UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open

___

Details:

sort (GNU coreutils) 5.97

The manual I'm looking at says "POS is  F[.C][OPTS], where F is  the field
number  and C the character  position  in the  field."

However, it'd be nice if it said "the first field in number 1".






___

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: coreutils-6.3 on MacOS X

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Here the problem is:
>   mbstate_t mbstate = {0};
> ISO C 99 guarantees only that mbstate_t is not an array type; it could
> be a scalar or pointer type.

But that's OK.  The initializer is valid C89 (and C99) even if
mbstate_t is a scalar or pointer type.  The following is standard C:

  int x = { 0 };

Similarly, the following is also valid C:

  mbstate_t mbstate = {0};

regardless of whether mbstate_t is a struct, or an array, or a scalar,
or a union.

Changing the code to use memset makes the code less readable and more
error-prone.  Also, it has some problems on implementations where null
pointers and/or floating point values do not have all-bits-zero
representation; a problem in this area is has almost zero probability
for GNU code and mbstate_t but if it's easy to make the code portable
then we might as well do so.

This subject has come up a couple of times before.  In

I noted that glibc now sometimes uses the following style when the
type isn't known to be a structure or a scalar:

   sometype somevar = { 0, };

as an indication to the reader as to what is going on.

The question is whether we want to use this style, which I think is
nicer, or cater to "gcc -Wall" even if its warning is
counterproductive.  Personally I'd rather do the former, so I'd prefer
the following patch, but it's really up to Jim.

2006-10-09  Paul Eggert  <[EMAIL PROTECTED]>

* lib/quotearg.c (quotearg_buffer_restyled): Use
initializer rather than memset to initialize an object
to zero.  This is easier to read and is less likely to
introduce an runtime error due to a mixup.  It causes
"gcc -Wall" to issue a warning, but you can work around
this by appending -Wno-missing-braces.
* src/ls.c (quote_name): Likewise.
* src/pathchk.c (portable_chars_only): Likewise.
* src/shred.c (main): Likewise.
* src/stty.c (main): Likewise.
* src/tr.c (card_of_complement): Likewise.
* src/wc.c (wc): Likewise.

Index: lib/quotearg.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/quotearg.c,v
retrieving revision 1.50
diff -p -u -r1.50 quotearg.c
--- lib/quotearg.c  3 Oct 2006 06:33:39 -   1.50
+++ lib/quotearg.c  9 Oct 2006 19:14:01 -
@@ -415,8 +415,7 @@ quotearg_buffer_restyled (char *buffer, 
  }
else
  {
-   mbstate_t mbstate;
-   memset (&mbstate, 0, sizeof mbstate);
+   mbstate_t mbstate = { 0, };
 
m = 0;
printable = true;
Index: src/ls.c
===
RCS file: /fetish/cu/src/ls.c,v
retrieving revision 1.442
diff -p -u -r1.442 ls.c
--- src/ls.c3 Sep 2006 02:53:16 -   1.442
+++ src/ls.c9 Oct 2006 19:14:17 -
@@ -3604,8 +3604,7 @@ quote_name (FILE *out, const char *name,
 reach its end, replacing each non-printable multibyte
 character with a single question mark.  */
  {
-   mbstate_t mbstate;
-   memset (&mbstate, 0, sizeof mbstate);
+   mbstate_t mbstate = { 0, };
do
  {
wchar_t wc;
Index: src/pathchk.c
===
RCS file: /fetish/cu/src/pathchk.c,v
retrieving revision 1.89
diff -p -u -r1.89 pathchk.c
--- src/pathchk.c   9 Oct 2006 11:56:41 -   1.89
+++ src/pathchk.c   9 Oct 2006 19:14:19 -
@@ -200,11 +200,8 @@ portable_chars_only (char const *file, s
 
   if (*invalid)
 {
-  mbstate_t mbstate;
-  size_t charlen;
-
-  memset (&mbstate, 0, sizeof mbstate);
-  charlen = mbrlen (invalid, filelen - validlen, &mbstate);
+  mbstate_t mbstate = { 0, };
+  size_t charlen = mbrlen (invalid, filelen - validlen, &mbstate);
   error (0, 0,
 _("nonportable character %s in file name %s"),
 quotearg_n_style_mem (1, locale_quoting_style, invalid,
Index: src/shred.c
===
RCS file: /fetish/cu/src/shred.c,v
retrieving revision 1.130
diff -p -u -r1.130 shred.c
--- src/shred.c 3 Sep 2006 02:53:16 -   1.130
+++ src/shred.c 9 Oct 2006 19:14:21 -
@@ -1091,7 +1091,7 @@ int
 main (int argc, char **argv)
 {
   bool ok = true;
-  struct Options flags;
+  struct Options flags = { 0, };
   char **file;
   int n_files;
   int c;
@@ -1106,8 +1106,6 @@ main (int argc, char **argv)
 
   atexit (close_stdout);
 
-  memset (&flags, 0, sizeof flags);
-
   flags.n_iterations = DEFAULT_PASSES;
   flags.size = -1;
 
Index: src/stty.c
===
RCS file: /fetish/cu/src/stty.c,v
retrievin

Re: fix coreutils' "make distcheck": remove AC_CONFIG_LIBOBJ_DIR(lib)

[Ralf Wildenhues]

Hello Jim, Eric,

* Eric Blake wrote on Sat, Oct 07, 2006 at 07:41:02PM CEST:
> According to Jim Meyering on 10/7/2006 10:06 AM:
> > [cc'ing bug-automake, in case this is a bug.
> >  I was using both automake-1.9b and the latest from cvs. ]

> [...] by using
> AC_CONFIG_LIBOBJ_DIR(gnu), automake creates gnu/gnu/.deps.  Somehow the
> directory is being inserted in there twice.

Bug in Automake.  Patch to appear on automake-patches.

Cheers,
Ralf


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

Re: coreutils-6.3 on MacOS X

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> This subject has come up a couple of times before.  In
> 
> I noted that glibc now sometimes uses the following style when the
> type isn't known to be a structure or a scalar:
>
>sometype somevar = { 0, };
>
> as an indication to the reader as to what is going on.
>
> The question is whether we want to use this style, which I think is
> nicer, or cater to "gcc -Wall" even if its warning is
> counterproductive.  Personally I'd rather do the former, so I'd prefer
> the following patch, but it's really up to Jim.

I do prefer your patch.
You're welcome to check that in.

> 2006-10-09  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * lib/quotearg.c (quotearg_buffer_restyled): Use
>   initializer rather than memset to initialize an object
>   to zero.  This is easier to read and is less likely to
>   introduce an runtime error due to a mixup.  It causes
>   "gcc -Wall" to issue a warning, but you can work around
>   this by appending -Wno-missing-braces.
>   * src/ls.c (quote_name): Likewise.
>   * src/pathchk.c (portable_chars_only): Likewise.
>   * src/shred.c (main): Likewise.
>   * src/stty.c (main): Likewise.
>   * src/tr.c (card_of_complement): Likewise.
> * src/wc.c (wc): Likewise.


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

Re: symlink calculation in bootstrap script

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Here's a patch to lift a few restrictions in the bootstrap script.

It's nice to lift restrictions, but that patch adds about 8.5 seconds
of CPU time and 11 seconds of real time to './bootstrap' on my
platform, and unless I'm missing something the restrictions don't seem
to apply to the way that bootstrap normally operates with coreutils.


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

Re: NSK(OSS) compilation problem

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:

So what would be your recommendation? Remove all use of 64-bit
integers? (i.e. make intmax_t also 'long' rather than 'long long'?)


No, I'd make uintmax_t 32-bit and intmax_t 64 bit, if those are
the widest unsigned and signed types.  Then I'd fix any bugs
that crop up.


Ok... Attaching an initial attempt at a patch for stdint_.h. The 
configure script (or more appropriately, I suppose, configure.in) needs 
to be patched additionally, but alas, I do not speak autotools :-), and 
didn't spot the sources anyway in my brief exploration looking for them. 
So ignore that part of the patch.


And remind me to *NEVER* try to update configure on this box; each run 
takes an *hour* (yes, this box sucks :-)). Trying to do so basically 
killed making any headway Friday.


At any rate, this is enough to get me started; I will have additional 
patches as bugs in single programs manifest themselves, but this at 
least gets things further along.




Anyway, this got me as far as sha512.c where the compiler croaked with:

...
   0x27b70a8546d22ffcULL, 0x2e1b21385c26c926ULL, 0x4d2c6dfc5ac42aedULL, 
0x53380d139d95b3dfULL, 0x650a73548baf63deULL, 0x766a0abb3c77b2a8ULL, 
0x81c2c92e47edaee6ULL, 0x92722c851482353bULL,
"/home/tandem_oss/floss/src/coreutils-6.3/lib/sha512.c", line 399: 
error(764):

  invalid unsigned type
Error limit reached.
100 errors detected in the compilation of "sha512.c".
Compilation terminated.

(So, yes... "yike"... Since this thread is already getting old (and 
likely to get a lot older before I'm done), should I continue this 
thread even if/when it starts falling off NTP, or start new ones?)


What exactly is sha512 used for? It is clear that this code is totally 
non-portable from the explicit use of 'uint64_t' in sha512.h. (Is this 
supposed to be excluded from the build, or what? It clearly would not 
build on any system without a 64-bit integer type...)




I also tried the patch on Solaris x86 (manually changing config.h and 
config.status); there were warnings in fsusage.c, and it failed 'make 
check' at cp:sparse, dd:skip-seek, du:basic, misc:printf, 
misc:split-fail, pr:pr-tests (and OMG was that a noisy failure!), 
tr:tr-tests (not as bad, but still noisy), and uniq:uniq-tests.




On an unrelated note, when running configure, I get these two header 
compilation failures:


...
configure: WARNING: sys/statvfs.h: present but cannot be compiled
...
configure: WARNING: sys/ioctl.h: present but cannot be compiled
...

For now I'm ignoring the ioctl.h one as I don't remember it being a 
problem. I'll look into the statvfs.h failure when I try to get 'stat' 
to build (contrary to my previous bug report, statvfs() looks OK so I'm 
not sure why I couldn't get 'stat' to build on 5.97 - I'm going to try 
harder this time). My guess, however, is that this is a case of needing 
_TANDEM_SOURCE defined ala http://savannah.gnu.org/bugs/?17172, but 
since this would need to be changed in autoconf I'm not sure what, if 
anything, should or could be done.


For statvfs.h:
"/usr/include/sys/statvfs.h", line 50: error(114): identifier "u_long" 
is undefined

(I get this on lines 35-43, 45, 46, 48-50)

Similarly for ioctl.h it complains about 'u_short', 'u_char', 'caddr_t', 
etc in "/usr/include/net/if_arp.h" and "/usr/include/net/if.h" which are 
of course inet headers, i.e. this failure exactly matches my description 
in the bug report.





I think there may be some problems with files that double-include
.  That is a no-no nowadays, since  redefines
uintmax_t and the like.  I'll try to look into it.


Thanks. (Hmm, that sounds like you got off on a tangent talking about
my Tru64 problem?)


I think the issues are related.


I don't see what including config.h twice has to do with HP NSK/OSS not 
having an 'unsigned long long' type? But thanks again for fixing that 
(assuming the patch worked, not sure when I might get around to trying it).


--
Matthew
"What's Cygwin?" you ask.
'Tis mostly absurd software
Concerning hippos.
diff -ur coreutils-6.3-orig/configure coreutils-6.3/configure
--- coreutils-6.3-orig/configure2006-09-30 02:09:13.0 -0700
+++ coreutils-6.3/configure 2006-10-09 10:29:25.0 -0700
@@ -715,6 +715,7 @@
 LIBICONV
 LTLIBICONV
 HAVE_LONG_LONG_INT
+HAVE_UNSIGNED_LONG_LONG_INT
 HAVE_WCHAR_H
 HAVE_INTTYPES_H
 HAVE_SYS_TYPES_H
@@ -17568,9 +17569,14 @@
 cat >>confdefs.h <<\_ACEOF
 #define HAVE_UNSIGNED_LONG_LONG_INT 1
 _ACEOF

   fi

+  if test $ac_cv_type_unsigned_long_long_int = yes; then
+HAVE_UNSIGNED_LONG_LONG_INT=1
+  else
+HAVE_UNSIGNED_LONG_LONG_INT=0
+  fi



@@ -62390,6 +62399,7 @@
 LIBICONV!$LIBICONV$ac_delim
 LTLIBICONV!$LTLIBICONV$ac_delim
 HAVE_LONG_LONG_INT!$HAVE_LONG_LONG_INT$ac_delim
+HAVE_UNSIGNED_LONG_LONG_INT!$HAVE_UNSIGNED_LONG_LONG_INT$ac_delim
 HAVE_WCHAR_H!$HAVE_WCHAR_H$ac_delim
 HAVE_INTTYPES_H!$HAVE_INTTYPES_H$ac_delim
 HAVE_SYS_TYPES_H!$HAVE_SYS_TYPES_H$ac_delim
@@ -62457

Re: coreutils CVS on NetBSD 3.0

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> filemode.c:171: warning: implicit declaration of function `strmode'

Thanks for reporting this.  It's better to fix this in filemode.h, for
the benefit of filemode's users, so I installed this into gnulib:

2006-10-09  Paul Eggert  <[EMAIL PROTECTED]>

* lib/filemode.h [HAVE_DECL_STRMODE]: Include unistd.h too,
for NetBSD.  Problem reported by Bruno Haible.

--- lib/filemode.h  3 Jul 2006 08:32:46 -   1.6
+++ lib/filemode.h  9 Oct 2006 19:33:34 -
@@ -22,7 +22,8 @@
 # include 
 
 # if HAVE_DECL_STRMODE
-#  include 
+#  include  /* FreeBSD, OpenBSD */
+#  include  /* NetBSD */
 # else
 void strmode (mode_t mode, char *str);
 # endif


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

Re: make it possible to avoid symlinks in coreutils' bootstrap

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Would you mind adding a --copy option to the bootstrap script? Roughly
> like this?

Good suggestion, yes.  I installed the following somewhat-different
patch, which is a bit more cautious about switching between a
bootstrap with and without --copy.  Also, it uses "cp -p", which
more-closely approximates the symlink and gives builders a better idea
of when the source file actually changed.

2006-10-09  Paul Eggert  <[EMAIL PROTECTED]>

* bootstrap (usage, main program, symlink_to_gnulib): Add option
--copy.  Inspired by a suggestion from Bruno Haible.

--- bootstrap   2 Oct 2006 11:47:35 -   1.19
+++ bootstrap   9 Oct 2006 20:33:11 -
@@ -40,6 +40,7 @@
   have gnulib sources on your machine, and
   do not want to waste your bandwidth dowloading
   them again.
+ --copy   Copy files instead of creating symbolic links.
  --force  Bootstrap even if the sources didn't come from CVS.
  --skip-poDo not download po files.
  --cvs-user=USERNAME  Set the CVS username to be used when accessing
@@ -112,6 +113,9 @@
 # the distributed version.
 CVS_only_file=CVS

+# Whether to use copies instead of symlinks.
+copy=false
+
 # Override the default configuration, if necessary.
 test -r bootstrap.conf && . ./bootstrap.conf

@@ -133,6 +137,8 @@
 SKIP_PO=t;;
   --force)
 CVS_only_file=;;
+  --copy)
+copy=true;;
   *)
 echo >&2 "$0: $option: unknown option"
 exit 1;;
@@ -249,29 +255,42 @@
 {
   src=$GNULIB_SRCDIR/$1
   dst=${2-$1}
-  dot_dots=
-
-  case $src in
-  /*) ;;
-  *)
-case /$dst/ in
-*//* | */../* | */./* | /*/*/*/*/*/)
-   echo >&2 "$0: invalid symlink calculation: $src -> $dst"
-   exit 1;;
-/*/*/*/*/) dot_dots=../../../;;
-/*/*/*/)   dot_dots=../../;;
-/*/*/) dot_dots=../;;
-esac;;
-  esac

   test -f "$src" && {
-test -h "$dst" &&
-src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
-dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
-test "$src_i" = "$dst_i" || {
-  echo "$0: ln -fs $dot_dots$src $dst" &&
-  ln -fs "$dot_dots$src" "$dst"
-}
+if $copy; then
+  {
+   test ! -h "$dst" || {
+ echo "$0: rm -f $dst" &&
+ rm -f "$dst"
+   }
+  } &&
+  test -f "$dst" &&
+  cmp -s "$src" "$dst" || {
+   echo "$0: cp -fp $src $dst" &&
+   cp -fp "$src" "$dst"
+  }
+else
+  test -h "$dst" &&
+  src_ls=`ls -diL "$src" 2>/dev/null` && set $src_ls && src_i=$1 &&
+  dst_ls=`ls -diL "$dst" 2>/dev/null` && set $dst_ls && dst_i=$1 &&
+  test "$src_i" = "$dst_i" || {
+   case $src in
+   /*) dot_dots=;;
+   *)
+ case /$dst/ in
+ *//* | */../* | */./* | /*/*/*/*/*/)
+echo >&2 "$0: invalid symlink calculation: $src -> $dst"
+exit 1;;
+ /*/*/*/*/)dot_dots=../../../;;
+ /*/*/*/)  dot_dots=../../;;
+ /*/*/)dot_dots=../;;
+ esac;;
+   esac
+
+   echo "$0: ln -fs $dot_dots$src $dst" &&
+   ln -fs "$dot_dots$src" "$dst"
+  }
+fi
   }
 }



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

Re: [date] ISO-8601 date format

[Paul Eggert]

[EMAIL PROTECTED] (Bob Proulx) writes:

> Paul, Shouldn't that be iso-8601 instead of iso-8602 in the above?

Yes, thanks, I installed this:

2006-10-09  Paul Eggert  <[EMAIL PROTECTED]>

* NEWS: Fix typo: iso-8602 -> iso-8601.  Problem reported by
Bob Proulx.

--- NEWS.~1.438.~   2006-10-03 15:11:50.0 -0700
+++ NEWS2006-10-09 13:36:02.0 -0700
@@ -638,7 +638,7 @@ GNU coreutils NEWS  
 
   cp and mv: the --reply=X option is deprecated
 
-  date accepts the new option --rfc-3339=TIMESPEC.  The old --iso-8602 (-I)
+  date accepts the new option --rfc-3339=TIMESPEC.  The old --iso-8601 (-I)
   option is deprecated; it still works, but new applications should avoid it.
   date, du, ls, and pr's time formats now support new %:z, %::z, %:::z
   specifiers for numeric time zone offsets like -07:00, -07:00:00, and -07.


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

Re: coreutils-6.3 on MacOS X

[Bruno Haible]

Paul Eggert wrote:
>   It causes "gcc -Wall" to issue a warning, but you can work around
>   this by appending -Wno-missing-braces.

The warning that this kind of initializer (with or without the trailing
comma) elicits with "gcc -W -Wall" on glibc systems is

  foo.c:3: warning: missing initializer
  foo.c:3: warning: (near initialization for 'm.__value')

To turn off this warning one needs to pass -Wno-missing-field-initializers.
But I don't think it's a good advice to tell people to use
-Wno-missing-field-initializers. This warning was introduced because it
can catch real, nasty programming errors (namely, when you have vtable-
like structs, like in the Linux kernel, and you add one element at the
end of the struct but forget to update some of the implementations).

Similarly, -Wno-missing-braces is also a useful one, because it catches
initializer bugs with nested structs and unions. It helped me more than one
in GNU clisp.

Globally I think it's a bad tradeoff to sacrifice a gcc warning for the
sake of 7 lines of code.

Bruno


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

Re: [date] ISO-8601 date format

[JL Lacroix]

2006/10/9, Bob Proulx <[EMAIL PROTECTED]>:

Basically fixed by the --rfc-3339 option for which you will need to
upgrade to a 6.x release.  Until then you will need to process the
date format and reformat it before passing it back to date.


Thanks. Using streamlined Debian distro on my servers, I guess I'll
have to wait a little ;=)

I will go for the replacement of T with a space.

Jean-Luc


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