Thanks for the report.
I believe this is not a bug in sort.
This misunderstanding may be due to a weakness in the documentation.
The way sort's -b modifier works is different from the way any of the other
modifiers work in that it means different things when applied to the
field-start than when
Bob Manson [EMAIL PROTECTED] writes:
| I guess this is more of a suggestion. I'm running RedHat 6.1 on an intel
| box.
[sort doesn't work properly when LC_ALL is set to en_US]
| I know how to get around this (at least *now* I do) by unsetting the
| LC_ALL environment variable, or setting it to
Martin Pool [EMAIL PROTECTED] writes:
| I have a functionality patch for GNU sort and ls in
|
| http://www.linuxcare.com.au/projects/natsort/
|
| I'm not sure it's exactly the right behaviour yet, but would be
| interested to hear what you think.
Please take a look at the existing code in the
Thanks for the report.
Please send any future reports to the mailing address listed in the
documentation ([EMAIL PROTECTED], [EMAIL PROTECTED]).
That problem is fixed in the latest releases.
ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0q.tar.gz
HERVE ARNAUD [EMAIL PROTECTED] writes:
| J ' ai divise un fichier grace a la commande split mais je n'arrive plus a
| recoller les morceaux .
| Je sais qu'il faut utilise la commande join mais le man de " join" n'est pas
|tres explicite
| et je n'arrive pas m'en sortir
Once you've split
That's the required behavior on such machines.
The order depends on the `endianness' of your system.
If you want output that is independent of the endianness,
the use a format like `-t o1':
$ echo hello|od -t cx1
000 h e l l o \n
68 65 6c 6c 6f 0a
006
Rick
This is not a bug in uniq.
It detects identical lines only if they're adjacent.
One way to remove all duplicates is to sort first:
sort myfile |uniq
Or use sort's -u option:
sort -u myfile
Matt Wolfe [EMAIL PROTECTED] writes:
| All,
|
| First of all thanks for the great product!
|
|
Thanks for the report and all the references.
Here's the fix (relative to the latest test release).
Now I get this:
$ yes |./head -08|wc -l
8
$ yes |./head -010|wc -l
10
Index: head.c
===
RCS file:
"craig martin" [EMAIL PROTECTED] writes:
| I wrote yesterday that "the sort utility program (written by Mike Haertel) that
| came with my Red Hat LInux 6.2 (obtained about April 2000) and that is part of
| the GNU textutils 2.0a (December 1999) seems to have a fundamental flaw". I
| have found
Natalie Knight [EMAIL PROTECTED] writes:
| I have shell script that is calling paste that is not acting as I would
| think that it would. When it gets to the paste part it should
| interpret the line as paste -d'\0' p[1-40] new.file
In case you haven't heard, you're misinterpreting what how
Rajesh Vaidheeswarran [EMAIL PROTECTED] writes:
| I just did a `man fmt' and it came up with
...
| ../src/fmt [-DIGITS] [OPTION]... [FILE]...
|
| I believe that the `../src/fmt' should just be `fmt', and maybe
| has been inserted as part of the build process.
Thanks for the report.
That's
[EMAIL PROTECTED] wrote:
| sort --version
| sort (GNU textutils) 2.0e
| Written by Mike Haertel.
|
| It places "@" ahead of "2"
|
| cat t.txt
| a
| 2
| @
|
| sort t.txt
| @
| 2
| a
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it
Jan Eggert Kofoed [EMAIL PROTECTED] wrote:
| I am sorry for bothering you, but now I see that my version 1.22 is too old,
| since it has been reported that 1.22q fixes the HP-UX problem with
| core-dump. Should I get version 2.0? Where do I get it?
The latest test release is here:
Thanks for the report.
That's fixed in the latest test release.
ftp://alpha.gnu.org/gnu/fetish/
$ printf '5:2:7 \n6:2:8\n' b
$ printf '1:2:3\n' a
$ join -t ':' -1 2 -2 2 a b|cat -A
2:1:3:5:7 $
2:1:3:6:8$
durif_philippe [EMAIL PROTECTED] wrote:
| I think there is a bug in "join" :
Werner Almesberger [EMAIL PROTECTED] wrote:
| When trying to build textutils-2.0 after an overly pessimistic configure
| run (due to a special build environment with newlib), I found the following
| two problems:
Thanks for the report and patches!
| - lib/memcoll.c should include sys/types.h
Thanks for the heads-up.
Even without looking at the actual bug report, I admit
that this is probably a good opportunity for optimization.
Of course, it'd be a trade-off (memory for speed), but it
sounds reasonable.
If you dive in, be sure to use the latest test release
(available soon):
Bill Unruh [EMAIL PROTECTED] wrote:
| Sort appears to have been created with the -f option as the default on
| later versions of Linux.
| Since there is no way to switch this off however, this is not a great
| default
You are using the version of sort that comes with textutils-2.0
or newer and
Thanks for the reports and for persisting :-)
I've adjusted the tests and renamed some files for the next test release.
Here's the mailing list information:
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-textutils
Index: Test.pm
Thanks for the report.
How about this patch?
Index: sample-vec
===
RCS file: /fetish/textutils/tests/sha1sum/sample-vec,v
retrieving revision 1.5
diff -u -p -r1.5 sample-vec
--- sample-vec 2000/11/03 11:12:01 1.5
+++ sample-vec
Jan Jannink [EMAIL PROTECTED] wrote:
| I'm using this version of sort:
|
| [jan@razor /tmp]$ sort --version
| sort (GNU textutils) 2.0.11
| Written by Mike Haertel.
|
| This file has been sorted:
|
| b_1-a
| b_1-a
| b1-a
| b_1-d
| b1-d2
| b1-d2
| b1-d_2
| b1-s
| b_1-w
| b_1-z
| b1-z
|
|
|
Thanks for volunteering.
That TODO list is pretty old.
Several items have been done or removed.
The latest test release is here:
ftp://alpha.gnu.org/gnu/fetish/fileutils-4.0.43.tar.gz
Something that I would really appreciate is if someone would run the
Open Group's VSC-lite test suite against
Till Halbach [EMAIL PROTECTED] wrote:
| I figured out that when I write
|
| head -n 07 filename.txt
| or
| head -n 10 filename.txt
|
| everything works fine, but for
|
| head -n 08 filename.txt
| or
| head -n 09 filename.txt
|
| I get
|
| head: 08: number of lines is so large that it is not
Soeren Sonnenburg [EMAIL PROTECTED] wrote:
| Hi, I want to report the following bug in the manpage of the 'comm' utility:
|
| Shouldn't it be common to both files instead of unique !!!?
Yes. Thanks!
I've corrected comm.c so that --help now outputs this:
$ ./comm --h|grep 3
-3
How about using awk or perl instead?
$ echo a b c d e| cut -d' ' -f 4,3
c d
vs.
$ echo a b c d e | awk '{ print $4, $3 }'
d c
$ echo a b c d e | perl -an -e 'printf $F[3] $F[2]\n'
d c
You could even use sed.
Martin Schulte [EMAIL PROTECTED] wrote:
| Sorry for writing to
Thanks a lot for the report.
I'll be sure this is fixed for the next test release.
Herbert Xu [EMAIL PROTECTED] wrote:
| This is caused by the overflowing of the COST type. On linux-i386, int and
| long are of the same length, thus defining the COST as long gains nothing.
| A maximum width
Herbert Xu [EMAIL PROTECTED] wrote:
| Full details are available at
| http://bugs.debian.org/80541
|
| In that thread, Christian Kurz also noted that FreeBSD's tail already
| supports a -F option whose behaviour is almost identical to this proposed
| option. The same is true in NetBSD.
Dan Jacobson [EMAIL PROTECTED] wrote:
| pr man page of GNU textutils 2.0 August 1999
|
| I see lots of indentation problems on this man page, e.g.
|
|-J, --join-lines
| merge full lines, turns off -W line truncation, no
| column alignment, -S[STRING]
This is a common problem.
Here's the canned reply:
--
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.
That is due not to a bug in sort, but to the fact that you have
set
SHREE RAMAN [EMAIL PROTECTED] wrote:
| I have used the sort utility with the sample input:
| a
| A
| The result expected was:
| A
| a
| But i had got the output :
| a
| A.
| Please help me out in this problem. Am i doing any
| mistake in giving the input or does the utility has
| some flaw.
You
Thanks for the report and patch.
That part of sort has been rewritten in recent test releases.
If you find that the latest version still has a problem,
please report it.
This is the latest test release:
ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.14.tar.gz
Ketil Froyn [EMAIL PROTECTED]
Robert Citek [EMAIL PROTECTED] wrote:
| I was working with sort and noticed that I got some errors when string
| lengths were multiples of 16. Here's a bash script to demonstrate the error:
|
| ( c=x; list=; length=0
| for length in $(seq 1 48); do
| echo length == ${length}
|
Frank Heckenbach [EMAIL PROTECTED] wrote:
| The TODO of textutils-1.22 said:
|
| sort: use strcoll for a slow-but-locale-aware mode
|
| In 2.0, this item seems to have disappeared, but I see no use of
| strcoll in the sources, either (and no new options that could
| activate it).
|
| What
Thanks for the report, but which version of sort are you using
and how/with-what-compiler was it compiled?
With 2.0(from debian) and with 2.0.14, I get this:
$ printf a\na b\n|sort -c -k1,1 echo ok
ok
Herbert Xu [EMAIL PROTECTED] wrote:
| The final newline is included in the final field
Greg Lindahl [EMAIL PROTECTED] wrote:
| bash$ more example
| 109 bar
| 111 b
| 111 a
| 1 10
| 9 foo
| bash$ sort -k 1,1rn -k 2,2 example
| 111 a
| 111 b
| 1 10
| 109 bar
| 9 foo
|
| It seems that the n is making sort ignore the separator, so it sorts
| 1 10 as if it were the number 110. That
Sergei Steshenko [EMAIL PROTECTED] wrote:
| Hello !
|
| I am using this version of 'sort' shipped with RedHat Linux 7.1:
|
|
| [15] 17:06 [EMAIL PROTECTED]:/home/sergei which sort
| /bin/sort
| [16] 17:06 [EMAIL PROTECTED]:/home/sergei /bin/sort --version
| sort (GNU textutils) 2.0.11
Thanks
Stephan Menezes [EMAIL PROTECTED] wrote:
| i have two simple text files FILE1andFILE2with the following
| contents
|
|
| FILE1
| FILE2
|
| ccode/server.c
| ccode/server1.c
| ccode/server1.c
|
|
| now when i COMM it
|
| $ comm -12 FILE1 FILE2
|
| it gives me no output . but
Jim Randell [EMAIL PROTECTED] wrote:
I have a problem with 'sort' core dumping on a certain file (for the
most part 'sort' seems to be performing normally).
I've attached an strace of the command generated with:
strace -o sort-2.0.11-trace sort sort-killer
I've not attached the input
Joaquim Francisco Ferreira da Silva [EMAIL PROTECTED] wrote:
Please Sir,
considering the followinf file f containing the following lines:
a , 1
a ; 2
a , 3
If i do: cat f | sort
sort will give
a , 1
a ; 2
a , 3
This is a frequently asked question.
Here's the explanation:
[EMAIL PROTECTED] wrote:
I have a little question. When I am working with my Terminal and ask him how
long the word counter is he tells me, oh, the word is longer than it is. For
example:
I tell him foo bar and I count up to seven characters, you know, he says
stupiderweise eight, damn it
Dan Gleeson [EMAIL PROTECTED] wrote:
I found a bug in /bin/sort.
Thanks for the report, but that's not a bug.
-
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.
That is due not
Herbert Xu [EMAIL PROTECTED] wrote:
...
(erno@fabulous) /tmp % fmt -w 10 /etc/fstab
[snip output]
zsh: segmentation fault (core dumped) fmt -w 10 /etc/fstab
Thanks for the report.
Here's a patch:
The command `echo foo| fmt -w 10' would cause fmt to segfault.
Chan Ting [EMAIL PROTECTED] wrote:
I found that there is the bug in standard linux sort program (textutils rpm)
version 2.0.11-7 which is included in redhat 7.1, then I update it to 2.0.14-2
but the problem still remain. Then I downgrade the rpm to textutils-2.0a-2, it
solved the problem.
Bob Proulx [EMAIL PROTECTED] wrote:
Peter
sort fails for me on the attached file. Here is all the version
information:
Thanks for the report and for supplying all of the needed version
information. That was great.
[urbi@lsec2 oracle]$ sort --version
sort (GNU textutils) 2.0e
Roth, Kevin P. [EMAIL PROTECTED] wrote:
My platform:
$ uname -a
CYGWIN_NT-5.0 FDYP143578 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown
I was attempting to get od to output hex characters and ascii characters lined
up on top of each other, like so:
000 t h i s i s
Thanks for the report and patch.
I'll request that it be fixed in the GNU C library (from whence
that file comes).
Uwe H. Steinfeld [EMAIL PROTECTED] wrote:
some systems do not #define __unbounded (e.g. Cygwin).
I suggest to add the following patch to lib/regex.c
Ernst Kloppenburg [EMAIL PROTECTED] wrote:
I am using 'tail' from textutils 2.0-6 on a Debian GNU/Linux system.
When tail is used in a pipe, it behaves strangely when the option
--follow=name is given. The behaviour I found strange is illustrated by the
following example:
1) tail -f
You wrote:
[...sort -M doesn't work the way I expect it to...]
Thanks for the report, but that's not due to a bug.
Two things might be causing trouble here:
- a common misunderstanding about how sort works with byte offsets:
without `-b' or the b attribute, each field includes leading
Vibhu Mohindra [EMAIL PROTECTED] wrote:
The man page says option -3 suppresses lines unique to both files. In fact -3
suppresses lines common to both files (as indicated by the info page for comm)
Thanks, but that's already fixed.
The latest is here:
Hi Tom,
[Bill, it looks like your problem is similar]
I think you're misreading the spec.
It says that if any per-key option is specified, then
that overrides all global ordering options for that key.
The following options shall override the default ordering rules.
When ordering options
Bill Peeler [EMAIL PROTECTED] wrote:
there appears to be a bug in the sort program.
sort (GNU textutils) 2.0a
...
sort -t , tiny_in -k 2nbd,2nbd -k 3nbd,3nbd -k 4nbd,4nbd -k 5nbd,5nbd
i ran it and got the following output:
...
input file:
3,20020109184710,30,2405,94,test
Pawel Prokop [EMAIL PROTECTED] wrote:
Hello I've found some problem with tr.
textutils version =2.0 and =2.0.18
linux kernel version 2.2.19, 2.2.20, 2.4.7, 2.4.16
pablo@glibc:~$ echo pawel prokop rulez | tr [::] _
tr: tr.c:816: substr: Assertion `first_idx = last_idx' failed.
Aborted
Jeff Dimond [EMAIL PROTECTED] wrote:
I looked where you said and I do not see 2.0.19. 2.0.18 is the latest
version under gnu/fetish. Where might 2.0.19 be?
Hmm... sorry about that.
I released 2.0.20 earlier today and have confirmed that it *is* there:
Matt Schalit [EMAIL PROTECTED] wrote:
Hi folks,
I need a copy of md5sum. So I decided to build textutils-2.0.18
on my UnixWare 7.1.1 box using gcc-2.95.3 and gmake.
I get the following error in regex.c, but I'm not skilled enough
to analyze it.
Hi Matt,
That was fixed in the
Luis Miguel [EMAIL PROTECTED] wrote:
Hi, I get the following:
###
(demo@rh71:~)$ history | grep epic | sort
Violación de segmento (core dumped)
(demo@rh71:~)$ file core
core: ELF 32-bit LSB core file of 'sort' (signal 11), Intel 80386, version 1, from
'sort'
Dan Jacobson [EMAIL PROTECTED] wrote:
Gee, I sure wish the GNU paste documentation mentioned a little of this.
Wonder where she learned all this. Wasn't from Info.
From: laura fairhead ([EMAIL PROTECTED])
Subject: Re: print line 1 of each file, line 2 of each file...
Newsgroups:
Col. G. L. Sicherman [EMAIL PROTECTED] wrote:
On RedHat 7.2, GNU sort dumps core if you specify -m and any file
argument but the last is empty.
Example:
$ sort -m /dev/null /etc/passwd
Segmentation fault
$
Thanks for the report.
That's fixed in 2.0.20 and in the latest
Tony Kocurko [EMAIL PROTECTED] wrote:
Hi,
I believe that lines 137 and 138 of od.c ought to be changed
from this:
sizeof (long int),
sizeof (float),
to this:
sizeof (long int),
sizeof (long long),
sizeof (float),
Without that change on our RedHat Linux 7.2 Intel
Eric Backus [EMAIL PROTECTED] wrote:
...
I have verified that MS Visual C++ 6.0 produces an error when given the
above code. I also verified that gcc 2.95.2 accepts it without any
warnings, but does produce a warning for it if given the -pedantic flag.
Thanks for pointing that out.
Here's an
stefano federici [EMAIL PROTECTED] wrote:
It seems that the -f option (that is the ignore-case option) of sort doesn't
work with accented characters. For example the following command
sort -f -k1 input.txt output.txt
where input.txt contains:
È 1
à 2
è 3
will output the following
Augey Mikus [EMAIL PROTECTED] wrote:
I've created a patch for the tail.c file of textutils which allows for
a time less than 1 for specifying refresh delay when following a file
with -f. I am however, wondering why this ability wasn't added
earlier. This option is available for other
Herbert Xu [EMAIL PROTECTED] wrote:
I'm getting complaints from Debian users regarding the output of
md5sum file, which is of the form:
d47fe6e8023a49af77e5885275d7242f -
The complainants would prefer to see:
d47fe6e8023a49af77e5885275d7242f
which is analogous to the behaviour cksum
Shei, Shing-Shong [EMAIL PROTECTED] wrote:
I recently compiled and installed textutils 2.1 on Solaris 2.7 and 2.8.
Today we found a strange behavior in the 'cat':
% cat /usr/demo/SOUND/sounds/ring.au /dev/audio
(or any small size audio files there) just produces a click sound while
Mikko Tuumanen [EMAIL PROTECTED] wrote:
$ tail --version
tail (textutils) 2.1
Written by Paul Rubin, David MacKenzie, Ian Lance Taylor, and Jim Meyering.
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty
Jack Moffitt [EMAIL PROTECTED] wrote:
The arch (http://www.fifthvision.net/open/bin/view/Arch) build system relies
on tsort to compute dependencies. The attached file when piped through
tsort results in drastically different results on my two systems, one
running tsort 2.0.21 as shipped with
Thanks for the report.
Would you please try the latest release? It may work better.
ftp://alpha.gnu.org/gnu/fetish/coreutils-4.5.3.tar.gz
If not, please look at config.log and see if you can find the cause.
Note that the package name has changed to coreutils.
Jost Martin [EMAIL PROTECTED]
Fabiani, Martin [EMAIL PROTECTED] wrote:
we have tested md5sum and found that it doesn't calculate the results of the
testcases in RFC1321 (see
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1321.html ). The same problem
appears to md5. The only solution we've found working correctly is the
Matt Rickard [EMAIL PROTECTED] wrote:
I have modified the GNU textutils tail.c to allow for fractional seconds
with the -s option. e.g. tail -f -s 1.325 filename, rather than only
whole number, as per the FIXME in the current tail.c code. The diff
follows.
Thanks for the patch.
That has
Julian Wald [EMAIL PROTECTED] wrote:
I think I've found a small bug in head. If you issue
head -n 09 file
head: 09: number of lines is so large that it is not representable
Thanks for the report.
That's been fixed for some time.
The latest release is here:
Chuck Simmons [EMAIL PROTECTED] wrote:
bash-2.05a$ tr '[:upper:][:punct:]' '[:lower:][ *]'
tr: tr.c:2003: main: Assertion `c1 == -1 || truncate_set1' failed.
Aborted
...
Thanks for the report.
Use `tr --version' to report which version of tr you're using.
I think that bug was fixed in
wiregauze [EMAIL PROTECTED] wrote:
...
--first-only option is found neither from man page nor
from `unexpand --help`.
(The option itself works fine since it is coded in the
source.)
Thanks for the report. I've fixed that.
In the next release --help output will look like this:
Usage:
Can cat -h be added as an alias of --help please?
You can use `--h' as an abbreviation for --help.
We try hard to avoid adding short-named options,
since they may conflict with options already used in other
implementations or in future standards.
Have you had the time to look at my wc reallines patch?
Thanks for the patch. I'm not sure it's worthwhile,
but am willing to be convinced. Making your argument in
the form of examples (diffs to coreutils.texi) demonstrating
the usefulness of the new option would help.
Here are some informal
Michael Bacarella [EMAIL PROTECTED] wrote:
How to reproduce:
1. Run md5sum interactively. Make sure you're using textutils
md5sum, some GNU/Linux distributions (like Debian) have their own
md5sum and rename the one from textutils to something like md5sum.textutils.
$
Bernhard Gabler [EMAIL PROTECTED] wrote:
we found a bug in join's self-documentation:
join --help
produces a help text which uses 'SIDE' to describe the -a and -v
options. However, the description of what SIDE stands for is missing.
The same bug appears in the man page to 'join'.
Thank
Haidong Wang [EMAIL PROTECTED] wrote:
With following two simple files:
test1:
a f
b h
c g
test2:
1 b
2 g
c 6
join -j 2 test1 test2
gives the wrong result which is nothing.
The correct result should be:
G c 2
Thank you for the report, but that is
Oliver Reiter [EMAIL PROTECTED] wrote:
I added support for sleeping fractional seconds to tail.
This is trivial but very useful, I hope it helps anyway.
Please consider adding this feature.
I put my patch under the GPL or LGPL, at your choice.
The complete, changed tail.c is added as
Uwe Zeisberger [EMAIL PROTECTED] wrote:
I'm not sure, if it's really a bug, but I expected something different:
echo lala | cut -f 1,1
reports lala only once.
Is it a bug or a feature?
Thank you for the report, but that is the required behavior.
Richard Kettlewell [EMAIL PROTECTED] wrote:
textutils 2.1 defines 'bool' as an enum and then uses it as the type
for a bit field member, which does not work on (at least) AIX. Patch
below.
Thank you for the report and patch.
That's fixed in the latest test release.
jason andrade [EMAIL PROTECTED] wrote:
Just letting you know i cannot get gnu-textutils 2.1 to compile
on SGI IRIX 5.3 (with the SGI IDO and all available public
patches applied)
I can't try gcc because gcc3 doesn't compiler on IRIX 5.3 either
as yet :-)
Thanks for the report.
This version
Haakon Riiser [EMAIL PROTECTED] wrote:
Are you interested in working on fmt.c?
As a contributor or the principal maintainer? I have no problem
As a contributor.
with the former, but I don't think it's a good idea for me to take
...
What else is on the to-do list?
See the TODO file here,
[EMAIL PROTECTED] wrote:
error in wc manpage:
wc - print the number of bytes, words, and lines in files
should be:
wc - print the number of lines, words, and bytes in files
Thanks for reporting that.
I've corrected that, as well as the similar problems in wc's --help
output and in the
Yuval Dinari [EMAIL PROTECTED] wrote:
(Well, this is not really a bug since the program behaves as specified)
wc -l counts the number of newlines. If the the file doesn't end
with a newline then
this number is less the the number of lines in the file.
Wouldn't it be nicer if wc would
Clement Wang [EMAIL PROTECTED] wrote:
echo foo |uniq -c
outputs:
1\tfoo
however, it seems like on other unix systems (e.g. tru64) uniq -c output
a space instead of a tab.
...
uniq (textutils) 2.0.14
Thank you for reporting that bug. POSIX requires a space.
It is present even in the
Thanks for reporting that.
Charles Karney [EMAIL PROTECTED] wrote:
Problem
The documentation for unexpand claims
* that only initial whitespace is converted (unless -a is given)
* that only sequences of 2 or more spaces are converted
Neither of these is true for nondefault tab
Ashley Sanders [EMAIL PROTECTED] wrote:
When running make check on a feshly compiled textutils-2.1
textutils-2.1 is rather old.
I suggest you use coreutils-5.0 or newer.
OFFICIAL
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.bz2
(coreutils is the union of fileutils, textutils, and
Nitin Gupta [EMAIL PROTECTED] wrote:
I downloaded textutils-2.1.tar.gz from gnu website.
I was trying to build textutils for our processor. I saved textutils
under CVS source control (which apparently changed the timestamps of
textutils-2.1 is getting old.
You're not the first to make the
Nitin Gupta [EMAIL PROTECTED] wrote:
I noticed that on textutils (after touching), even if I have automake version
1.7, it was asking me to have 1.6b.
I'm using automake-1.7.6 and autoconf-2.57 and have no problem.
If you have errors with older versions, please upgrade.
If you have problems
Brent Wood [EMAIL PROTECTED] wrote:
I was using the command
cat $FILE | head -1 | wc -w
to get the number of words (columns) in a line of a file
This worked until the number of words got over a certain number (I haven't
checked to find out where, but it looks like about 10,000)
Thanks for
Grant Ballard [EMAIL PROTECTED] wrote:
I can't get tr to redirect to a file or pipe to another command.
Is there something I'm doing wrong (or a version that handles this better)?
specific command syntax
tr -d \ test.txt
INPUT:
d5902589
desired OUTPUT:
d5902589
That works fine for me.
[EMAIL PROTECTED] (Antonomasia) wrote:
[EMAIL PROTECTED] pha_nt]$ sort --version
sort (GNU textutils) 2.0e
Thanks for the report.
That version is pretty old. There have been numerous improvements.
Please see if you can reproduce the problem with a newer version:
STABLE
John Sellers [EMAIL PROTECTED] wrote:
Attached are 3 files
tosort - to be sorted
badsort- what tsort in cygwin does
goodlist - what tsort that works does (stnderr redirected)
What version of tsort are you using?
It's not very recent, based on the output you include.
I suggest you try a newer
Alex Cherepanov [EMAIL PROTECTED] wrote:
The cast is missing in lib/fnmatch_loop.c distributed with
textutils-2.1. . The patch is attached.
Thank you for the patch.
That's fixed in the latest coreutils release:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz
92 matches
Mail list logo
