Re: tsort with odd number of items does not give an error.

[Jim Meyering]

address@hidden wrote:
>     $ tsort --version
>     tsort (coreutils) 4.5.4
>     Written by Mark Kettenis.
>
>     Copyright (C) 2002 Free Software Foundation, Inc.
>     This is free software; see the source for copying conditions.  There is NO
>     warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
> PURPOSE.
>
> The Info page describes:
>
>    `tsort' reads its input as pairs of strings, separated by
>    blanks, indicating a partial ordering.  The output is a total
>    ordering that corresponds to the given partial ordering.
>
> I am not quite sure what "as pairs of strings" exactly means
> when there are more then two tokens on a line.  Does the

A NEWLINE byte counts as a blank, here.
There are a couple of examples in the texinfo documentation.
Look at `info tsort'.

Also, coreutils-4.5.4 is a few months old,
you might want to use coreutils-5.0:

  ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.bz2

> following mean "a < b && c < d" (no ordering is specified
> between b and c), or "a < b && b < c && c < d"?  What the
> implementation does implies the former:
>
>     $ echo a b c d | tsort
>     a
>     c
>     b
>     d

So the above is equivalent to

  printf 'a b\nc d\n' | tsort

> However, then what does the following mean?
>
>     $ echo a b c | tsort
>     a
>     c
>     b

In coreutils-5.0, the above is equivalent to

  printf 'a b\nc c\n' | tsort

which means a must precede b, and c is present and may appear anywhere.
But I've just read the POSIX spec and experimented with a few other
implementations.  They all seem to agree that tsort should fail in
this case, so I've made the change.

> It is clear from the output this does not mean "a < b && b < c"
> to the implementation.  But it gets worse.
>
>     $ (echo a b c; echo c a) | tsort
>     a
>     c
>     b

This will now evoke an error.

> The second line explicitly specifies "c < a" but the output does

The input is not line-oriented.

> not honor that.  It appears that the only sane interpretation of
> the behaviour of the implementation is that the entire output is
> undefined when there is a line with an odd number of items in
> the input, and no error diagnosis is made.  I think it should at
> least complain about such an input.

Thanks for the report.