3 ms·

Can you say more about how stderr is monitored? Are you capturing it with a pipe, or do you have another technique? Have you run into problems with commands tha

Can you say more about how stderr is monitored? Are you capturing it with a pipe, or do you have another technique? Have you run into problems with commands that tailor their output to the tty, like clang does? Also how does it work with job control?

hnlmorg 6y ago
> 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).
- ridiculous_fish 6y ago
  Wait it's interposing stdout as well? How do programs like vim work if they aren't connected to the tty?
  - hnlmorg 6y ago
    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).

hnlmorg 6y ago

> 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).

ridiculous_fish 6y ago
Wait it's interposing stdout as well? How do programs like vim work if they aren't connected to the tty?
- hnlmorg 6y ago
  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).