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!
Nor should he, IMO. Hacky workarounds are almost always a terrible idea that will bite you in the ass someday.
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.
But yeah, for production quality software hacks are the very last resort. It's still fun and enlightening to know them, though.
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.
The following custom command is executed for starting the terminal
/usr/bin/zsh -c 'export SCRIPT_LOG_FILE_NAME=$(date "+%m-%d-%y-%H-%M-%S-%N") && mkdir -p /tmp/script-log/ && script -f -q /tmp/script-log/$SCRIPT_LOG_FILE_NAME'
export SCRIPT_LOG_FILE_NAME=$(date "+%m-%d-%y-%H-%M-%S-%N")
mkdir -p /tmp/script-log/
script -f -q /tmp/script-log/$SCRIPT_LOG_FILE_NAME
export SCRIPT_LOG_FILE_NAME=$(date "+%m-%d-%y-%H-%M-%S-%N")
mkdir -p /tmp/script-log/
script -f -q /tmp/script-log/$SCRIPT_LOG_FILE_NAME
We can split the log at the last $PS1 prompt and feed the most recent chunk to a utility such as Simon W.'s llm.
Add the following to .zshrc (or …):
alias z='tail -n 100 /tmp/script-log/$SCRIPT_LOG_FILE_NAME | llm -s "Fix it or similar" | pbcopy'
ranger_danger•1d ago
https://strace.io/
https://github.com/nelhage/reptyr
https://github.com/crigler/dtach
https://github.com/jerome-pouiller/reredirect
https://github.com/pasky/retty
jmclnx•1d ago
Then there is this method, but I guess that article refers to no redirection output.
If in background or via cron, I always redirect. But this is for UN*X type systems with a tail that supports '-f'
$ prog > /tmp/log.txt 2>&1 &
Then
$ tail -f /tmp/log.txt
Just so happens, I actually used this the other day for a long running process on OpenBSD :)
hmng•1d ago
$ prog | tee /tmp/log.txt
gosub100•1d ago
maxjohan•1d ago
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.
$ sway |& tee /tmp/sway.log
$ tail -f /tmp/sway.log
yjftsjthsd-h•1d ago
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.
maxjohan•1d ago
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?
toast0•1d ago
https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0&s...
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?
maxjohan•1d ago
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 :)
ranger_danger•1d ago
maxjohan•19h ago
toast0•1d ago
maxjohan•19h ago
baobun•1d ago
https://news.ycombinator.com/item?id=46234678
zaius•1d ago
mzs•1d ago
(one login session, say over serial)
(another session, say over telnet) (first session ie SERIAL) (otherone eg TELNET) teeheeheehaw!