On Tuesday May 05 2015 10:19:28 Mihai Moldovan wrote: >> apart from the weird fact that this apparently is the whole log, I wonder if >> there would be a way to avoid the abort on the flush error. It's not the >> first time I run into something like this, and it's rather annoying (the >> upgrade should have finished by now if it weren't for that otherwise trivial >> flush error). > >The error isn't weird. The terminal STDOUT/STDERR/STDIN were connected to all >of
Never said that. >a sudden vanished. What's weird about erroring out in such a case, especially >if >the kernel is telling your application that it couldn't handle a write >operation >on some specific FD? But thinking about it, there's something that does strike me as odd. All the output goes to the log, and only part of it goes to the tty (I did a `port -v upgrade`). I don't know how that's accomplished, but the file descriptor corresponding to the log file should not disappear. >If you want to be able to "call it a night", start port like any other process >on UNIX-like operating systems -- within tmux or screen, so that the file "start like any other process on UNIX-like operating systems" ... I'm sure that sounded different in your head... In any case, tmux and screen are both overkill, or would require me to kill the running port command to relaunch it before I leave it to its own. I don't know tmux, but screen tends to get in my way with its attempt to be clever with the scrollback buffer etc. Guess I'll have to try nohup and see if that does what I want. R. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
