Thanks for the report.
Andrew Mauer-Oats <[EMAIL PROTECTED]> writes:
| (1) I do not know the proper behavior for tsort, but it would be convient
| if it wrote out something for every node even if a cycle is detected.
| The current behavior is not to write out the nodes in the cycle, I
| believe.
|
| This is a problem when using the "lorder *.o | tsort" idiom for
| building archives, since some object files never appear in that list.
|
| Example
| cycle.o cycle.o
| cycle.o two.o
| two.o two.o
| two.o cycle.o
That was fixed in the 2.0d test release:
Here's the NEWS item:
* tsort now works more like the traditional UNIX tsort. Before it would
exit when it found a loop. Now it continues and outputs all items.
The latest test release is here:
ftp://alpha.gnu.org/gnu/fetish/
| (2) Also, I believe that there is a bug in the messages printed by tsort.
| I have appended the example which I experienced; I have not attempted
| to reduce it in size. (Sorry.)
|
| The bug is:
| tsort: -: input contains a loop:
|
| tsort: context_find.o
| tsort: strcasecmp.o
|
| But the loop is actually (as reported by solaris tsort):
| UX /usr/ccs/bin/tsort: INFORM: cycle in data
| path.o
| m_maildir.o
| context_find.o
With the latest version, I get the following using your input.
That looks right since there is indeed a loop consisting of path.o
and m_maildir.o (but not involving context_find.o):
$ tsort < /tmp/k > /dev/null
tsort: -: input contains a loop:
tsort: path.o
tsort: m_maildir.o
[Exit 1]
