Raymond's posts are always fun to read, but it sometimes he focuses more on the "proper" methods, and does not even acknowledge that there are hacky workarounds.
Like for this case - sure, you cannot redefine the standard output handle, but that's not what the customer asked for, is it? They said "read" and I can see a whole bunch of ways to do so - ReadConsoleOutput + heuristic for scrolling, code inject into console host, attach debugger, set up detour on logging function, custom kernel module...
To be fair, as a MS support person, it's the exactly right thing to do. You don't want the person to start writing custom kernel module when they should redirect stdout on process start instead. But as a random internet reader, I'd love to read all about hacky ways to achieve the same!
> Raymond's posts are always fun to read, but it sometimes he focuses more on the "proper" methods, and does not even acknowledge that there are hacky workarounds.
Nor should he, IMO. Hacky workarounds are almost always a terrible idea that will bite you in the ass someday.
As a hacker, I'm sorry, reverse engineer hacky workarounds is what I do. When I want to read stdout of a malware process I'm not going to ask a developer nicely, in going to grab my trusty debugger or API monitor.
But yeah, for production quality software hacks are the very last resort. It's still fun and enlightening to know them, though.
Had a WPF touch interface application that would latch on when a person; presses, holds, and slides their finger off the screen. Highly unacceptable when it controls a machine that could remove a limb.
Only fix was to write a custom touch screen event handler that overrides the built in one by Microsoft.
I would love to have a _proper method_ and pull out my _hacky_ method that prevents the removal of a person's limb.
Hacky workarounds aren't rare exceptions; they're the plumbing of modern software. Anti-cheat and antivirus tools only work because they lean on strange kernel behaviors. Cloud platforms ship fixes that rely on undefined-but-stable quirks. Hardware drivers poke at the system in ways no official API ever planned for.
Yeah, they're ugly, but in practice the choice isn't between clean and hacky; it's between shipping and not shipping. Real-world software runs on constraints, not ideals.
On the other hand, everything you ship outside of a clearly established golden path is a maintenance burden that piles and piles and piles. And these maintenance burdens tend to gradually slow the org down until they cause rather catastrophic failures, usually out of security or hardware (read: fire) incidents. Or HR reasons because people figure there are better places to fight fires.
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.
Is there a way to read everything from tty, from within the tty?
Neither of the methods below work, because the warnings/errors aren't produced by Sway itself, but some other OS module/component.
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?
You'll capture everything and maybe be able to figure it out from there?
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.
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:
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.
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?
-> ioTaskStdGet 0, 1
value = 3 = 0x3
-> taskIdSelf
value = 13600784 = 0xcf8810
(another session, say over telnet)
-> ioTaskStdSet 0xcf8810, 1, 0x9
value = 0 = 0x0
(first session ie SERIAL)
-> printf "foo\n"
-> taskIdSelf
-> i
(otherone eg TELNET)
-> foo
value = 4 = 0x4
value = 13600784 = 0xcf8810
NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
...
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.
That's if you start the process with advance knowledge that you'll want to tail the output and log it. Not if you want to view the output of an existing process
Or you could patch the executable on disk or in memory, or probably some other hacks I'm not thinking of. I think he means that there's no Windows API or "proper" way to do it, not that it's literally impossible (it's running on a general-purpose computer, after all).
Like for this case - sure, you cannot redefine the standard output handle, but that's not what the customer asked for, is it? They said "read" and I can see a whole bunch of ways to do so - ReadConsoleOutput + heuristic for scrolling, code inject into console host, attach debugger, set up detour on logging function, custom kernel module...
To be fair, as a MS support person, it's the exactly right thing to do. You don't want the person to start writing custom kernel module when they should redirect stdout on process start instead. But as a random internet reader, I'd love to read all about hacky ways to achieve the same!
reply