On Mon, 06 Jan 2014 15:52:08 +0100, Mark Wielaard wrote:
> The default output should be useful as is.
Which it is not. As for the common case of stack overflow by infinite loop it
does not show the reason.
> Of course they can tweak if however they want.
> eu-stack has many options to tailor the output to your need.
The problem is that:
* One should not need to tweak a program to perform its primary functionality.
* It leads to bugs as in 95% of cases it does what one expects so external
tools will forget passing -n 0 to it, breaking only later on more
complicated input data.
> But by default it provides [n=2048] frames for all threads of a process.
> A bit too much for my liking,
It is too much to print on a console anyway while it is still breaking the
stack overflow crashes. It is had only two cons, no pro.
> But I do think even without a tty one should be explicit
> about what one wants.
One is explicit already by calling eu-stack. Command "eu-stack" does not
suggest me it is in fact "eu-bottom-of-stack".
> > Paging, a-la git,
[...]
> > applying a default limit only when stdin is a tty would still be better,
> > IMO.
>
> I think that is a little too fancy, but yeah, that could have been
> another choice. But I do think even without a tty one should be explicit
These are all valid choices. And not breaking the primary functionality of
eu-stack.
> BTW. What does seem useful is a new (default) option --tail, that would
> only show the last n frames of each thread's backtrace.
For tail there is /usr/bin/tail:
https://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix
Write programs that do one thing and do it well. Write programs to
work together. Write programs to handle text streams, because that is
a universal interface.
The same way there is /usr/bin/head or /usr/bin/less.
> If detection of infinite backtraces can be done reliably.
It is always reliable.
Jan
