_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) How can I read the standard output of an already-running process?
jeffrallen wrote 9 hours 47 min ago:
strace (8).
bh0k4l wrote 12 hours 43 min ago:
How I use the script command to read the output of the last command and
ask an LLM for help:
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
The date sub-command creates a unique filename for the current session
and stores it in SCRIPT_LOG_FILE_NAME.
export SCRIPT_LOG_FILE_NAME=$(date "+%m-%d-%y-%H-%M-%S-%N")
Create a folder in /tmp/script-log/.
mkdir -p /tmp/script-log/
Script then writes the current terminal session to that file.
script -f -q /tmp/script-log/$SCRIPT_LOG_FILE_NAME
Now any command run in this terminal knows where the last program wrote
its output.
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'
Essentially, run a command; if it fails, run z.
bmacho wrote 11 hours 55 min ago:
On HN you can have a code block by adding 2 spaces before each line
theamk wrote 13 hours 25 min ago:
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!
bigstrat2003 wrote 12 hours 55 min ago:
> 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.
yndoendo wrote 5 hours 27 min ago:
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.
integralid wrote 10 hours 39 min ago:
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.
AmazingTurtle wrote 12 hours 5 min ago:
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.
tetha wrote 10 hours 4 min ago:
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.
amelius wrote 16 hours 12 min ago:
Can't you attach to it from GDB?
gary_0 wrote 15 hours 48 min ago:
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).
ranger_danger wrote 16 hours 13 min ago:
I know this article is for Windows, but if you're wondering if there's
a way to do this on Linux, there is: [1] [2] [3] [4]
(HTM) [1]: https://strace.io/
(HTM) [2]: https://github.com/nelhage/reptyr
(HTM) [3]: https://github.com/crigler/dtach
(HTM) [4]: https://github.com/jerome-pouiller/reredirect
(HTM) [5]: https://github.com/pasky/retty
mzs wrote 10 hours 12 min ago:
vxworks 6.x:
(one login session, say over serial)
-> 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
---------- ------------ -------- --- ---------- -------- --------
------- -----
...
teeheeheehaw!
zaius wrote 11 hours 45 min ago:
Here's my method using GDB from many years ago:
(HTM) [1]: https://gist.github.com/zaius/782263
baobun wrote 11 hours 47 min ago:
This prompted me to ask the crowd about a similar use-case of editing
your command line as it's already running your command
(HTM) [1]: https://news.ycombinator.com/item?id=46234678
maxjohan wrote 14 hours 19 min ago:
Is there a way to read from present tty?
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
toast0 wrote 13 hours 43 min ago:
If things are printed on top of each other, try script? [1] 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?
(HTM) [1]: https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0...
maxjohan wrote 13 hours 21 min ago:
Thanks for the input! Sounds promising. I've to admit, 'script'
doesn't say anything to me yet. I've to look into it.
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 :)
toast0 wrote 11 hours 4 min ago:
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.
ranger_danger wrote 13 hours 10 min ago:
If script doesn't work, you could maybe try starting everything
from within GNU screen or tmux with logging turned on?
yjftsjthsd-h wrote 14 hours 8 min ago:
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.
maxjohan wrote 13 hours 26 min ago:
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?
jmclnx wrote 15 hours 36 min ago:
Thanks, links saved.
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 :)
smcameron wrote 14 hours 37 min ago:
Can't you just read from /proc/pid/fd/0 ?
irishcoffee wrote 13 hours 30 min ago:
This was my first thought as well. I assume somehow I'm the dummy
that doesn't understand the question.
hmng wrote 15 hours 15 min ago:
Isn't that what tee is for? Like
$ prog | tee /tmp/log.txt
gosub100 wrote 15 hours 4 min ago:
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
(DIR) <- back to front page