macports with closed stdout

[René J.V. Bertin]

On Tuesday May 05 2015 19:58:44 Clemens Lang wrote:

>They don't, but they will fail equally in the situation you describe.

Then why didn't they? When I tested my patch, I closed the ssh connection almost immediately after starting the upgrade (of 2 ports), so there should have been ample occasion for these flushes to be called...

>paths that call the progress callbacks deal with errors in these callbacks, but

As they ought to. Progress indication is a convenience to the user that should never interfere with the process it measures...

>you would at least get uncommon error messages in your log file, and potentially
>lots of them.

Well, that's hard to tell, because apparently the log is truncated when the activation phase begins. I never noticed this before, but then I rarely check the log after a successful install ...

>Well, in this case -v disabled the progress bars and thus this code path. Since
>-v is not the default I would expect a comprehensive test to also test this,
>which you did not, or you would have seen the broken progress bars.

Without a terminal to show them? :)

>That sounds like a perfect use case for screen or tmux.

I might check out tmux, but screen gets in my way by trying to be too clever. The easiest would be to redirect all output (">&") to file and then use tail -f until I decide to disconnect. Or maybe it'll be enough to pipe all output to cat, or otherwise an application that redirects it output elsewhere if stdout/stderr are closed (I think I must have something like that lying around). More often than not all that interests me when reconnecting is if the port command completed successfully, because if not there are logs already.

>wrapper for flush that wraps it in catch, where should you put it from a software
>design point of view? If it's used from both macports1.0 and port.tcl, there's
>no good place in the MacPorts source tree to put it, because we want to keep
>dependencies between these two modules small.

I'll pretend I haven't understood since the beginning of this exchange that nothing will change and give a rhetorical answer to a rhetorical question ... :)
You'll have to compromise and chose which design principle is more important (limiting interdependencies or avoiding code duplication in this case).
Or maybe it can go into the C source base (pextlib?). Or patch the dedicated tclsh. Enough possibilities.

R