Re: Bug in autoconf 2.62 with old GNU awk

['Ralf Wildenhues']

* Daniel Richard G. wrote on Sat, Dec 13, 2008 at 10:37:30PM CET:
> Here is the real problem---not gawk(1), but indeed tr(1):
> 
> % ( echo foo ; echo bar ) | tr '\015\012' ' '
> foo
> bar
> % ( echo foo ; echo bar ) | tr '\015\012' '  '  < note the two-space 
> string
> foo bar %
> 
> The expected "SET2 is extended to length of SET1 by repeating its last 
> character as necessary" thing is not happening!

Posix leaves this unspecified, in order to allow for the historical
System V semantics.

Cheers,
Ralf


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

timespec declaration issue on Tru64 (was: Bug in autoconf 2.62 with old GNU awk)

[Ralf Wildenhues]

[ adding bug-gnulib, removing bug-autoconf ]

* Daniel Richard G. wrote on Sat, Dec 13, 2008 at 11:16:28PM CET:
> However, I'm running into a more tricky issue during the build...
> 
> source='sig2str.c' object='sig2str.o' libtool=no  DEPDIR=.deps depmode=tru64 
> /bin/ksh ../build-aux/depcomp  cc -std -std  -I.-ieee   -g -c -o 
> sig2str.o 
> sig2str.c
> cc: Error: /usr/include/sys/timers.h, line 107: The member "it_interval" has 
> an incomplete type. (incompmem)
> struct  timespec it_interval; /* timer interval */
> -^
> cc: Error: /usr/include/sys/timers.h, line 108: The member "it_value" has an 
> incomplete type. (incompmem)
> struct  timespec it_value; /* current value */
> -^
> *** Exit 1
> Stop.

Yes, this is where I got stuck, too, on OSF/Tru64 4.0D.  I haven't been
able to get to the bottom of it yet, but it seems that there is some
impedance mismatch between the replacement header lib/time.h and the
headers included by /usr/include/time.h.  struct timespec is defined in
/usr/include/sys/sysmisc.h, but somehow the inclusion tree ends up
expanding use before definition.

Cheers,
Ralf


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

stty doc 'enhancements'

[jidanni]

On (info "(coreutils)stty invocation")
say what you mean by Input Settings and Output Settings.
I.e., what you type into the terminal and then goes into... what is
sent from the computer to your terminal...??

After
 `iuclc'
 Translate uppercase characters to lowercase.  Non-POSIX.  May be
 negated.
mention there is no corresponding item to Translate lowercase
characters to uppercase.

Same with lcase, say "ucase" is missing.

Same at
 `olcuc'
 Translate lowercase characters to uppercase.  Non-POSIX.  May be
 negated.
mention there is no 'ouclc' currently.

(They all might be needed when trying to emulate some early computer
system or something one day.)


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

[PATCH] getopt: Indicate the problem with ambiguous options clearly.

[James Youngman]

---
 ChangeLog|6 ++
 lib/getopt.c |   25 +
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7faac2b..b593588 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-14  James Youngman  
+
+   getopt: Indicate the problem with ambiguous options clearly. 
+   * lib/getopt.c (_getopt_internal_r): Print the first and second
+   possibility when there is an ambiguous match.
+
 2008-12-14  Bruno Haible  
 
Update doc for POSIX:2008.
diff --git a/lib/getopt.c b/lib/getopt.c
index f1e6d1f..107538f 100644
--- a/lib/getopt.c
+++ b/lib/getopt.c
@@ -480,8 +480,8 @@ _getopt_internal_r (int argc, char **argv, const char 
*optstring,
   char *nameend;
   const struct option *p;
   const struct option *pfound = NULL;
+  const struct option *pambig = NULL;
   int exact = 0;
-  int ambig = 0;
   int indfound = -1;
   int option_index;
 
@@ -512,19 +512,25 @@ _getopt_internal_r (int argc, char **argv, const char 
*optstring,
 || pfound->has_arg != p->has_arg
 || pfound->flag != p->flag
 || pfound->val != p->val)
- /* Second or later nonexact match found.  */
- ambig = 1;
+ {
+   /* Second or later nonexact match found.  We remember
+  it instead of breaking out of the loop in case
+  there is a later exact match to be found.  */
+   pambig = p;
+ }
  }
 
-  if (ambig && !exact)
+  if (pambig && !exact)
{
  if (print_errors)
{
 #if defined _LIBC && defined USE_IN_LIBIO
  char *buf;
 
- if (__asprintf (&buf, _("%s: option `%s' is ambiguous\n"),
- argv[0], argv[d->optind]) >= 0)
+ if (__asprintf (&buf, _("%s: option `%s' is ambiguous, "
+ "since for example it might mean --%s or 
--%s\n"),
+ argv[0], argv[d->optind],
+ pfound->name, pambig->name) >= 0)
{
  _IO_flockfile (stderr);
 
@@ -539,8 +545,11 @@ _getopt_internal_r (int argc, char **argv, const char 
*optstring,
  free (buf);
}
 #else
- fprintf (stderr, _("%s: option `%s' is ambiguous\n"),
-  argv[0], argv[d->optind]);
+ fprintf (stderr, _("%s: option `%s' is ambiguous, "
+"since for example it might mean --%s or 
--%s\n"),
+  argv[0], argv[d->optind],
+  pfound->name, pambig->name);
+ 
 #endif
}
  d->__nextchar += strlen (d->__nextchar);
-- 
1.5.6.5



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

Re: [PATCH] getopt: Indicate the problem with ambiguous options clearly.

[Bruno Haible]

James Youngman wrote:
> +2008-12-14  James Youngman  
> +
> + getopt: Indicate the problem with ambiguous options clearly. 
> + * lib/getopt.c (_getopt_internal_r): Print the first and second
> + possibility when there is an ambiguous match.

The patch looks good. But the master sources of the 'getopt' module are in
glibc, Have you tried submitting your patch as a glibc bug in
? (Patches sent to the libc-alpha mailing
list sometimes get forgotten; submission through bugzilla is more reliable.)

Bruno


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

Re: [PATCH] getopt: Indicate the problem with ambiguous options clearly.

[James Youngman]

On Sun, Dec 14, 2008 at 7:05 PM, Bruno Haible  wrote:
> James Youngman wrote:
>> +2008-12-14  James Youngman  
>> +
>> + getopt: Indicate the problem with ambiguous options clearly.
>> + * lib/getopt.c (_getopt_internal_r): Print the first and second
>> + possibility when there is an ambiguous match.
>
> The patch looks good. But the master sources of the 'getopt' module are in
> glibc, Have you tried submitting your patch as a glibc bug in
> ? (Patches sent to the libc-alpha mailing
> list sometimes get forgotten; submission through bugzilla is more reliable.)

Thanks for the tip, I've added
http://sourceware.org/bugzilla/show_bug.cgi?id=7101

James.


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

Re: timespec declaration issue on Tru64

[Bruno Haible]

Ralf Wildenhues cited Daniel Richard G. and wrote:
> > However, I'm running into a more tricky issue during the build...
> > 
> > source='sig2str.c' object='sig2str.o' libtool=no  DEPDIR=.deps 
> > depmode=tru64 
> > /bin/ksh ../build-aux/depcomp  cc -std -std  -I.-ieee   -g -c -o 
> > sig2str.o 
> > sig2str.c
> > cc: Error: /usr/include/sys/timers.h, line 107: The member "it_interval" 
> > has 
> > an incomplete type. (incompmem)
> > struct  timespec it_interval; /* timer interval */
> > -^
> 
> Yes, this is where I got stuck, too, on OSF/Tru64 4.0D.  I haven't been
> able to get to the bottom of it yet, but it seems that there is some
> impedance mismatch between the replacement header lib/time.h and the
> headers included by /usr/include/time.h.  struct timespec is defined in
> /usr/include/sys/sysmisc.h, but somehow the inclusion tree ends up
> expanding use before definition.

The usual way to debug this kind of things is
  1) to look at the preprocessor output. Here:
 $  cc -std -std  -I.-ieee   -g -E sig2str.c > i
 Does this output contain the typedef for 'struct timespec' or not?
 If so, does it use the definition from  or from gnulib?
  2) to try different compiler standard flags. What does "cc -std" mean,
 according to the manual pages? What effect does it have to compile
 without the "-std" option?

Bruno


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

Re: stty doc 'enhancements'

[Pádraig Brady]

jida...@jidanni.org wrote:
> On (info "(coreutils)stty invocation")
> say what you mean by Input Settings and Output Settings.
> I.e., what you type into the terminal and then goes into... what is
> sent from the computer to your terminal...??
> 
> After
>  `iuclc'
>  Translate uppercase characters to lowercase.  Non-POSIX.  May be
>  negated.
> mention there is no corresponding item to Translate lowercase
> characters to uppercase.
> 
> Same with lcase, say "ucase" is missing.
> 
> Same at
>  `olcuc'
>  Translate lowercase characters to uppercase.  Non-POSIX.  May be
>  negated.
> mention there is no 'ouclc' currently.
> 
> (They all might be needed when trying to emulate some early computer
> system or something one day.)

For documentation changes like this it may be easier and less ambiguous
to write the docs as you would like and send a patch.
I find it much more difficult to accurately describe changes I would like.

In this case you just need to edit the texi file like:

git clone git://git.sv.gnu.org/coreutils/
cd coreutils
./bootstrap
./configure
cd doc
#edit coreutils.texi as required
make
git diff > stty-info.diff

cheers,
Pádraig.


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

RE: timespec declaration issue on Tru64

[Daniel Richard G.]

> -Original Message-
> From: bug-coreutils-bounces+oss=teragram@gnu.org
> [mailto:bug-coreutils-
> bounces+oss=teragram@gnu.org] On Behalf Of Bruno
> Haible
>
> The usual way to debug this kind of things is
>   1) to look at the preprocessor output. Here:
>  $  cc -std -std  -I.-ieee   -g -E sig2str.c >
> i
>  Does this output contain the typedef for 'struct
> timespec' or not?
>  If so, does it use the definition from
>  or from gnulib?

>From "egrep '^#|timespec' i" ...

# 582 "/usr/include/sys/types.h"
# 35 "/usr/include/sys/sysmisc.h"
typedef struct timespec {
} timespec_t;
# 35 "/usr/include/sys/siginfo.h"

>   2) to try different compiler standard flags. What
> does "cc -std" mean,
>  according to the manual pages? What effect does
> it have to compile
>  without the "-std" option?

-std puts the compiler into relaxed-ANSI mode, instead of the default, which 
is K&R. This flag was actually added by autoconf itself---the build failure I 
quoted was obtained with all *FLAGS variables unset.

(The only other options here are -std1 [strict ANSI], and -ms [Microsoft 
Visual C compatible])


--Daniel




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

Re: timespec declaration issue on Tru64

[Bruno Haible]

Daniel Richard G. wrote:
> -std puts the compiler into relaxed-ANSI mode, instead of the default, which 
> is K&R. This flag was actually added by autoconf itself---the build failure I 
> quoted was obtained with all *FLAGS variables unset.
> 
> (The only other options here are -std1 [strict ANSI], and -ms [Microsoft 
> Visual C compatible])

OK. It's the "strict" modes that sometimes cause trouble. "Relaxed" mode sounds
fine.

> >   1) to look at the preprocessor output. Here:
> >  $  cc -std -std  -I.-ieee   -g -E sig2str.c >
> > i
> >  Does this output contain the typedef for 'struct
> > timespec' or not?
> >  If so, does it use the definition from
> >  or from gnulib?
> 
> From "egrep '^#|timespec' i" ...
> 
> # 582 "/usr/include/sys/types.h"
> # 35 "/usr/include/sys/sysmisc.h"
> typedef struct timespec {
> } timespec_t;
> # 35 "/usr/include/sys/siginfo.h"

So? What is your conclusion from that?

Bruno


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

RE: timespec declaration issue on Tru64

[Daniel Richard G.]

> -Original Message-
> From: Bruno Haible [mailto:br...@clisp.org]
> >
> > From "egrep '^#|timespec' i" ...
> >
> > # 582 "/usr/include/sys/types.h"
> > # 35 "/usr/include/sys/sysmisc.h"
> > typedef struct timespec {
> > } timespec_t;
> > # 35 "/usr/include/sys/siginfo.h"
>
> So? What is your conclusion from that?

Well, that was meant to answer the question of whether struct timespec was 
coming from gnulib, or the system header. The only conclusion I draw is that 
Tru64 is a PITA to deal with :-)

Anyway, I was playing around with this a bit more. The compiler is choking 
somewhere inside the #include at the top of sig2str.c. Without fully 
grokking the rat's nest of #includes that lead up to the error, I found that 
adding the following line makes the problem go away:

begin sig2str.c snippet
#include 

#include 
#include < skadoosh
#include 
#include 
#include 
#include 

#include "sig2str.h"
end sig2str.c snippet

Everything else builds fine. Although I did run into one curious Make error 
(using /usr/bin/make):

begin build log excerpt
rm -f t-ref-del.sed ref-del.sed
sed -e '/^#/d' -e 's/@''PACKAGE''@/coreutils/g' ref-del.sin > t-ref-del.sed
mv t-ref-del.sed ref-del.sed
Making all in src
Make: bad lock name:  chcon chgrp chown chmod cp dd dircolors du ginstall link 
ln dir vdir ls mkdir mkfifo mknod mktemp mv nohup readlink rm rmdir shred stat 
sync touch unlink cat cksum comm csplit cut expand fmt fold head join groups 
md5sum nl od paste pr ptx sha1sum sha224sum sha256sum sha384sum sha512sum shuf 
sort split sum tac tail tr tsort unexpand uniq wc basename date dirname echo 
env expr factor false id kill logname pathchk printenv printf pwd runcon seq 
sleep tee test timeout true truncate tty whoami yes base64.  Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.
end build log excerpt

GNU Make got through that without a problem, but... should gmake be a 
prerequisite for building coreutils?


--Daniel




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