Dear GNU maintainer/team/email-dude,
in thre process of writing an Atom-feed-generator in bash, I discovered what
MIGHT be a bug/documentation misinterpretation in GNU date's --iso-8601
switch when invoked with ns or seconds as a parameter.
RFC3339 and some documents regarding ISO 8601 I could
On Fri, 22 Aug 2008, Johannes Truschnigg wrote:
in thre process of writing an Atom-feed-generator in bash, I discovered
what MIGHT be a bug/documentation misinterpretation in GNU date's
--iso-8601 switch when invoked with ns or seconds as a parameter.
--iso-8601 is deprecated since coreutils
Thanks for the quick and very clear explanation, Bob! I saw the
--ignore-case option definition, but the implications of it weren't
immediately apparent to me. It was especially confusing because I was
comparing with the output of a different tool which folds to lowercase when
doing comparisons
Dear maintainers,
There is a bug in the implementation of the -L parameter in wc.
It is triggered by
http://www.ime.usp.br/~am/122/eps/gapqm2.gz
Check this out:
$ zcat gapqm2.gz |wc -l -c -L
1 6297954 6353180
That is, the single line is longer than the whole file.
This was pointed out
Arnaldo Mandel [EMAIL PROTECTED] wrote:
Dear maintainers,
There is a bug in the implementation of the -L parameter in wc.
It is triggered by
http://www.ime.usp.br/~am/122/eps/gapqm2.gz
Check this out:
$ zcat gapqm2.gz |wc -l -c -L
1 6297954 6353180
That is, the single line is
Ben Pfaff [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Ludovic Courtès) writes:
Would you be OK to relicense `count-one-bits' under LGPLv2+ for use in
Guile 1.9 (aka. the development branch)?
I don't know who gets to make these decisions, but as the
module's maintainer I'm fine with that.
My earlier bug report lacked a pssibly relevant piece of info:
The bug showed up with versions 6.10 and 5.97 of wc, on Linux 2.6.24
and 2.6.11, i686 and x86_64, LC_ALL=C.
am
--
Arnaldo Mandel
Departamento de Ciência da Computação - Computer Science Department
Jim Meyering [EMAIL PROTECTED] wrote:
Arnaldo Mandel [EMAIL PROTECTED] wrote:
Dear maintainers,
There is a bug in the implementation of the -L parameter in wc.
It is triggered by
http://www.ime.usp.br/~am/122/eps/gapqm2.gz
Check this out:
$ zcat gapqm2.gz |wc -l -c -L
1 6297954
Jim Meyering wrote:
I'm tempted to make the change, but it seems too drastic, after 11 years.
Do any of you rely on the current TAB-counting behavior of GNU wc?
Hi,
It looks like TAB characters aren't alone in being counted by printed
width rather than count:
$ echo '好' | wc -L
2
Does it
Bo Borgerson wrote (on Aug 22, 2008):
Does it make sense to change the behavior for TAB, but not for wide
characters?
Relying on an undocumented tab length seems bad. However, on chars I
suggest you just apply the bug-feature operator: document that line
length is in chars, and explain
Hi Jim,
This behavior is not specified, and is currently untested.
(it's a GNU invention, from Bruno Haible in textutils-1.22d,
which was back in 1997)
The intention of this option is and was to measure the maximum number of
screen columns used by a file. For many purposes, people are
11 matches
Mail list logo
