This is how I've been doing it. I'm not sure exactly what you mean by filter, but Command 1 output:
of the echo
gives you the means to work with the log file.
#!/bin/bash
set -x
my_command() {
command1_output=$(command1)
echo "Command 1 output: $command1_output"
# Add more commands as needed
}
my_command >> my_logging_file 2>&1
Sometimes set -x
is too much info. You can run tail -f my_logging_file
from another terminal and watch it in real-time.
Update for comment:
Avoid the log and initiate, piped to tail
, to observe immediately.
#!/bin/bash
set -x
my_command() {
command1_output=$(command1)
echo "Command 1 output: $command1_output"
# Add more commands as needed
}
my_command 2>&1 | tail -f /dev/stdin
Function my_command
is executed, and it's stdout
and stderr
are piped to tail -f /dev/stdin
.
Whereas script
logs stdout & stderr, it's intended to "record" the entire session and then "played" back. You can use:
script my_session.log
# Your commands here
exit 0
Then, use scriptreplay my_session.log
to watch the session.
The expect
command is a scripting language for automating interactive programs. (i.e. commands that require user input.)
For example:
#!/usr/bin/expect
spawn my_command
expect "Input:" # Replace with expected prompt
send "input_value\r"
expect eof
This automates interactions with my_command by waiting for the specific prompt, then sending the chosen input.
script
solve your problem? – Panki Jan 03 '24 at 18:43expect
(a name that's unfortunately hard to search for, but try https://unix.stackexchange.com/search?tab=votes&q=expect%20tcl%20is%3aa&searchOn=3 for examples). Expect is a TCL library, and many languages now have a library, e.g. pyexpect in Python. @Pankiscript
is fine for logging but not convenient to filter the output in real time. – Gilles 'SO- stop being evil' Jan 03 '24 at 19:33socat
. However,socat
is an extremely complicated tool, nothing like a classical Unix tool that does one thing and does it right. It would take quite a bit of effort to understand how exactly make it do what I want. In addition, it has limitations: at least, you can’t have it run arbitrary commands easily, because it can’t cope well with clashes between the command and its own syntax; so it’s difficult to use in a general script. – Wolfgang Jeltsch Jan 03 '24 at 21:46/usr/bin/expect
as providing the environment to trick the first program into acting as if its output were going to a terminal. Then the expect script or other pipeline commands can filter and read the output as you desire. – Sotto Voce Jan 03 '24 at 23:48expect
seems to be one solution. Usingsocat
would be another one. My preliminary attempt issocat -u EXEC:⟨command⟩,pty FD:1 | ⟨filter-program⟩
. However, if⟨filter-program⟩
works line-wise, like most Unix text filters (sed
, for example), then this doesn’t play well with interactivity. – Wolfgang Jeltsch Jan 04 '24 at 00:45git diff
,git add --patch
, etc., but maybe that’s not a good idea, not least because the conversion would affect also parts that are not source code (although LaTeX-like commands would be unlikely to appear there). – Wolfgang Jeltsch Jan 04 '24 at 00:48unbuffer
? Or with theisatty
trick? If for some reason they don't satisfy your needs, please [edit] your question to provide specific examples of the limitation of those solutions and what would you expect? – aviro Jan 04 '24 at 14:19