> does `bg` return the `fid`
There's two kinds of process IDs in Murex: FID (function IDs) and PID (process IDs)
Forking is expensive in POSIX and has a number of drawbacks such as the inability to share scoped variables without resorting to environmental variables. So a FID is basically a PID but managed inside the scope of Murex's runtime. You can manage FIDs in much the same way as you can manage PIDs, albeit using Murex builtins rather than coreutils (though PID management tools in Bash are technically builtins rather than coreutils too).
What this means in practice is you can have entire blocks of code pushed into the background, eg
» GLOBAL.name = "rendaw"
» bg { sleep 5; echo "Hello $name" }; echo "not bg"
not bg
Hello rendaw
You can see the FID as well as the job ID the usual way, via `jobs`
» jobs
JobID FunctionID State Background Process Parameters
%1 2109 Executing true exec sleep 5
...and you can kill that entire `bg` block too
fid-kill 2109
But you'd also see any non-builtins in `ps` too:
» ps aux | grep sleep
hnlmorg 72749 0.0 0.0 410743712 1728 s012 S+ 4:24p.m. 0:00.00 /usr/bin/grep --color=auto sleep
hnlmorg 72665 0.0 0.0 410593056 432 s012 S+ 4:23p.m. 0:00.00 /bin/sleep 5
> Can you use those in scripts, or are they hobbled the same way bg/fg are in bash?
While the above seems very complicated, the advantage is that `bg` and `fg` become much more script friendly.
> - System-wide config file, I use Nixos and manage my system config using that
This isn't Murex's default behaviour but you could easily alter that with environmental variables: https://murex.rocks/user-guide/profile.html#overriding-the-d...
The latest version of Murex (v7.0.x), which is due to be released in the next few days, makes this even easier with a $MUREX_CONFIG_DIR var that can be used instead of multiple specific ones.
> - Background task support - I need to start an ssh tcp proxy, pipe a command over it, then kill ssh once the command is done (all in a script).
Murex has another layer of support for piping in addition to those defined in POSIX, which are basically channels in the programming language sense. In murex they're called "Murex Named Pipes" but the only reason for that is that they can be used as a glue for traditional POSIX pipes too. This is one area where the documentation could use a little TLC: https://dev.murex.rocks/commands/pipe.html
> - Post-command hook, to send a notification when a long command finishes
There are two different events you can hook into here:
- onPrompt: https://dev.murex.rocks/events/onprompt.html
This is similar to Bash et al prompt hooks
- onCommandCompletion: https://dev.murex.rocks/events/oncommandcompletion.html
This hooks into any command name that's executed. It runs the comment in a new TTY and buffers the command's output. So, for example, if you want a command like `git` to automatically perform a task if `git push` fails with a specific error message, then you can do that with onCommandCompletion.
> - Async iteration of command output, i.e. streaming events with swaymsg subscribe and running a command when certain events occur
I'd need to understand this problem a little more. The channels / Murex Named Pipes above might work here. As might onCommandCompletion.
> - Value/call arity safety - i.e. a clear distinction between a single value and multiple values that doesn't rely on stringification hacks. I.e. in `command $x` `command` should always have one argument, regardless of the contents of `x`, and making that plural should be explicit.
This one is easy: scalars are always $ prefixed whereas arrays are @ prefixed. So take the following example:
array = %[ a b c ]
» echo $array
["a","b","c"] # a single parameter representation of the array
» echo @array
a b c # the array expanded as values
-----
This is quite a lengthy post but hope it helps answer a few questions