I know this article is for Windows, but if you're wondering if there's a way to do this on Linux, there is:<p><a href="https://strace.io/" rel="nofollow">https://strace.io/</a><p><a href="https://github.com/nelhage/reptyr" rel="nofollow">https://github.com/nelhage/reptyr</a><p><a href="https://github.com/crigler/dtach" rel="nofollow">https://github.com/crigler/dtach</a><p><a href="https://github.com/jerome-pouiller/reredirect" rel="nofollow">https://github.com/jerome-pouiller/reredirect</a><p><a href="https://github.com/pasky/retty" rel="nofollow">https://github.com/pasky/retty</a>
Here's my method using GDB from many years ago: <a href="https://gist.github.com/zaius/782263" rel="nofollow">https://gist.github.com/zaius/782263</a>
Is there a way to read from present tty?<p>In practice: I boot into tty and manually start the graphical session (Wayland/Sway). I occasionally get (non-Sway) warnings when I return to tty (eg close the window manager). But the output is always scuffed, so I can't read the whole log. The lines get printed on top of each other or something.<p>Is there a way to read everything from tty, from within the tty?<p>Neither of the methods below work, because the warnings/errors aren't produced by Sway itself, but some other OS module/component.<p>$ sway |& tee /tmp/sway.log<p>$ tail -f /tmp/sway.log
If things are printed on top of each other, try script?<p><a href="https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0&sektion=1&manpath=FreeBSD+15.0-RELEASE+and+Ports&arch=default&format=html" rel="nofollow">https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0&s...</a><p>But, if you're getting console debugs from the kernel, that wouldn't be captured either... Otoh, debug output from the kernel should also go into logs or dmesg or something?<p>You'll capture <i>everything</i> and maybe be able to figure it out from there?
Thanks for the input! Sounds promising. I've to admit, 'script' doesn't say anything to me yet. I've to look into it.<p>About the logs, yes, I have yet to dive into that. The _everything_ part makes it very tedious, so I had hoped for another solution :)
If script doesn't work, you could maybe try starting everything from within GNU screen or tmux with logging turned on?
oh, one more thing... your pipeline is only capturing stdout; errors often get logged to stderr ... script (or screen/tmux logging) will capture both though.
It might be useful to try and figure out what's logging the messages.<p>However, if it was me, I'd strongly consider just starting from your shell in the tty, then running tmux, then starting sway, then attaching to tmux from a terminal emulator.
Thanks for your reply! I've thought about that as well. Haven't tried it though. Two thoughts about it:<p>1. Running graphical from within tmux feels unsafe (?). Introducing another layer can't be the way to go. BUT this comes from a position of limited knowledge, so I might stand corrected on this one. Also, doing it once for debugging won't do any harm.<p>2. I'm pretty sure the errors are not printed by Sway itself, but some other OS module. Errors that Sway cause for other modules won't be included in the Sway log. So the problem remains, no?
This prompted me to ask the crowd about a similar use-case of editing your command line as it's already running your command<p><a href="https://news.ycombinator.com/item?id=46234678">https://news.ycombinator.com/item?id=46234678</a>
vxworks 6.x:<p>(one login session, say over serial)<p><pre><code> -> ioTaskStdGet 0, 1
value = 3 = 0x3
-> taskIdSelf
value = 13600784 = 0xcf8810
</code></pre>
(another session, say over telnet)<p><pre><code> -> ioTaskStdSet 0xcf8810, 1, 0x9
value = 0 = 0x0
</code></pre>
(first session ie SERIAL)<p><pre><code> -> printf "foo\n"
-> taskIdSelf
-> i
</code></pre>
(otherone eg TELNET)<p><pre><code> -> foo
value = 4 = 0x4
value = 13600784 = 0xcf8810
NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
...
</code></pre>
teeheeheehaw!
I assume roughly the same caveats would apply, though? Buffering might be set wrong (and have no mechanism to be updated because the program never checks again), etc.
Thanks, links saved.<p>Then there is this method, but I guess that article refers to no redirection output.<p>If in background or via cron, I always redirect. But this is for UN*X type systems with a tail that supports '-f'<p>$ prog > /tmp/log.txt 2>&1 &<p>Then<p>$ tail -f /tmp/log.txt<p>Just so happens, I actually used this the other day for a long running process on OpenBSD :)