[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tsort with odd number of items does not give an error.
From: |
Jim Meyering |
Subject: |
Re: tsort with odd number of items does not give an error. |
Date: |
Sat, 26 Apr 2003 08:39:18 +0200 |
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.