Having skimmed the README, I failed to grasp what it is. I would appreciate it if the README featured a clear one-sentence summary of what the tool does. Like...
> cat - concatenate files and print on the standard output
> nohup - run a command immune to hangups, with output to a non-tty
> at — execute commands at a later time
Anyway, it's good to see new conceptual tools being developed for the Unix Toolbox, keep up!
> Build targets clean, depends, all, without occupying the terminal
This accommodates a workflow where one wouldn't prefer to just open up another terminal to do other stuff (maybe you're not in a graphical environment, maybe there's no tmux, etc.). With just the shell features, one could do `make ... && make ... && make ... &`, but that would cause bothersome output that would prevent you from effectively working in the same terminal. One could redirect the output of those commands, but then you lose it, or you have to think of where to collect it. This provides an alternative where you can background and still have convenient access to the output when you need it.
It also offers a better history UX. For example, if you issued,
make .. && make foobar && make ..
and you wanted to just run 'make foobar' again you'd search your history for the last foobar invocation, and be required to do some editing. With nq this wouldn't be necessary.
It's also not clear to me if nq has '&&' or ';' semantics in the event a command fails. I suspect it's ';'.
It probably isn't as user friendly as you'd want, but you can reload the playlist by firing commands at a socket. See the "JSON IPC" section in the mpv man page, and specifically the load* commands. jo¹ and socat² are probably the simplest way to use it if you're not looking for heavy scripting.
The scriptability of mpv is really nice if you're the sort of person who likes building your perfect environment, and also a huge pit of addictive time sinks. </warning>
"Lightweight" adds nothing to the description and "job" is ambiguous. I think "nq - queues the execution of background processes" would be a better description.
How is it in practice different to something like:
cmd && cmd2 &
edit: From reading other comments I guess the difference is not mainly that it keeps running if the shell dies but that it allows you to easily append new stuff to the end of the queue
Using ; will not work if you ran set -e before (eg.: if you're using it in a script). Perhaps more importantly, cmd1; cmd2 & will not work either, you'll need a subshell. So, you need at least: ( set +e; cmd1 ; cmd2 ) &. And there are probably other caveats. And we haven't even got to the output redirection yet.
From the reading of the text, it’s a serialized job queue for arbitrary commands submitted from the command line. It’s the equivalent of “cmd1 & cmd2 & cmd3” except all are put to the background and will be run serially one after another. And new command is automatically added to the end.
> cat - concatenate files and print on the standard output
> nohup - run a command immune to hangups, with output to a non-tty
> at — execute commands at a later time
Anyway, it's good to see new conceptual tools being developed for the Unix Toolbox, keep up!