On Tue, Jun 19, 2007 at 01:53:26PM +0200, Dag Wieers <[EMAIL PROTECTED]> wrote:
> > than once before as well), I think I'll patch it out of the Debian package.
>
> I think the reason why on Debian it's not liked is because it behaves
> differently than Red Hat/CentOS/Fedora in this regard.
While it is possible that it is not liked on debian, the explanation bears no
logic. bash does not, in this respect, work any differently than on any other
distro: with a single exception, bash works as on other distros.
The default might be different, who knows, but you are not talking about
defaults.
> As I said, I'm interested to change it in such a way that it works
> correctly in both situations.
It doesn't work correctly in any situation. The bug might simply be masked
by somethign the users prompt or prompt comamnd does, but surely you do
not believe that bash is the only way to start dstat? (If you are: no, you
cna start dstat from another program, too, lets call it zsh. You can even
write your own program to do it).
You have to understand that destroying information never works "correctly"
unless you restore it. It might be *masked* or might might not be
*important* information that is destroyed, it is even possible that users
of diferent distros have distinct different tastes with regards to thei
destruction: some might care, some might not, but you can't help it:
information is being destroyed.
So please separate yourself from the idea that you can do it "correctly"
by relying on something external to fix it up.
> I added it because it was useful in the same situation where dstat was
> useful and I see it as an integer part of dstat.
Nobody doubts that it can be useful. I think in most situations it is not
useful, but even I can imagine that there are uses for that feature. I could
even imagine that most people find it useful in a majority of situations.
But regardless, it never is always usefull to everybody who finds dstat
useful, and given that the feature is not at all cleanly implemented or
graceful, it should be made optional.
> (if you interactively monitor 5 to 10 clusters, you need a way to find out
> which output belongs to what machine and space is scarce)
So use the window title. I do that all the time, I do not need dstat to do
it, because I can configure it much better on my own.
The problem is that dstat doesn't give a shit to my carefully crafted
window titles and destroys them with soemthing much less useful to me.
You *have* to understand that something that is useful to you is nto
automatically useful to others.
Which is, in itself, not a problem. It becomes a problem if the
implementation of the feature is of either low enough quality that it
doesn't work well (in the case of dstat setting the window title: it is
not being restored).
> I have no problem if you patch it out as long as you add an option to
> enable it when users require it. In fact, if you like I can produce a
> patch to do this and ship it with dstat ? Is that useful ?
Very.
And it would also be very useful to have some .dstat like file where you
could put configuration items. I use this function for eternity now:
cmd_ds() {
exec dstat $(cat ~/.dstat) "$@"
}
Because my machines differ in configuration and I want to monitor
different disks on diferent machines. Yes, I know I can change the source,
but I deem changing the source and programming in python not a useful way
to configure my apps).
Greetings,
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
