> Can you say more about how stderr is monitored? Are you capturing it with a pipe, or do you have another technique?
STDERR is read by murex and then printed to the TTY. It's a massive cheat but it does mean I can also colourise easily errors in red. However you can disable this interception and have processes write directly to the TTY with the following command
config set proc force-tty true
> Have you run into problems with commands that tailor their output to the tty, like clang does?
Generally no because STDOUT is linked to the TTY (as long as the process isn't piped). But Bash does get upset if launched from within murex. Hence the following function is hardcoded in murex to wrap around `bash`:
# Wrapper script around GNU bash
config: set proc force-tty true
if { $ARGS -> len -> = -1 } then {
exec bash @{ $ARGS -> @[1..] }
} else {
exec bash
}
> Also how does it work with job control?
It does, but only with external commands (builtins aren't forked processes so adding job control to them is harder - a manual job rather than something given for free from POSIX).
Additionally when you stop a running process (^Z) murex outputs some status information on said process. eg
~ » exec sleep 10; echo hello
^Z
STDIN: 0 bytes read / 0 bytes written
STDOUT: 0 bytes read / 0 bytes written
STDERR: 0 bytes read / 0 bytes written
FID 429 has been stopped. Use `fg 429` / `bg 429` to manage the FID or `jobs` or `fid-list` to see a list of processes running on this shell.
~ » jobs
PID State Background Process Parameters
429 Stopped false exec sleep 10
~ » fg 429
hello
You can also write your own shell scripts that get invoked whenever you do ^Z too (eg if you want to output additional information on said PID).
NB A bit of background on the FID vs PID. PID is obviously the UNIX process ID. But since murex builtins aren't forked they're not given a PID yet you might still want to manage that function. So murex has a "function ID" (FID) which is an additional layer of process management. It's a bit of a kludge to get around the shortcomings of not forking murex but it kind of works (the reason murex doesn't fork builtins is itself a shortcut to allow richer pipelines).
It's only proxying STDOUT if STDOUT is a pipe. If it isn't (which it wouldn't be if you're running `vim`) then the STDOUT is the TTY as usual.
eg
vim # `vim`s STDOUT is a TTY
vim | cat # `vim`s STDOUT is a pipe but `cat`s STDOUT is a TTY
In that regard, murex isn't really any different to any other shell. As in `vim | cat` would produce the same "Warning: Output is not to a terminal" error in bash, zsh or murex. But the difference with murex is when two processes are piped together, murex acts as a proxy. So it's a bit like this: `vim | murex | cat` (to borrow the 2nd example above).
STDERR is read by murex and then printed to the TTY. It's a massive cheat but it does mean I can also colourise easily errors in red. However you can disable this interception and have processes write directly to the TTY with the following command
> Have you run into problems with commands that tailor their output to the tty, like clang does?Generally no because STDOUT is linked to the TTY (as long as the process isn't piped). But Bash does get upset if launched from within murex. Hence the following function is hardcoded in murex to wrap around `bash`:
> Also how does it work with job control?It does, but only with external commands (builtins aren't forked processes so adding job control to them is harder - a manual job rather than something given for free from POSIX).
Additionally when you stop a running process (^Z) murex outputs some status information on said process. eg
You can also write your own shell scripts that get invoked whenever you do ^Z too (eg if you want to output additional information on said PID).NB A bit of background on the FID vs PID. PID is obviously the UNIX process ID. But since murex builtins aren't forked they're not given a PID yet you might still want to manage that function. So murex has a "function ID" (FID) which is an additional layer of process management. It's a bit of a kludge to get around the shortcomings of not forking murex but it kind of works (the reason murex doesn't fork builtins is itself a shortcut to allow richer pipelines).