rancid_par(1)

πŸ’– rancid_par(1) β€” the General Commands Manual page, but make it a group chat πŸ’–

okay so bestie, welcome to rancid_par β€” parallel command processing ✨ that's the whole vibe. it's the rancid_par(1) page and we're gonna get through it together, no cap.


✨ NAME ✨

rancid_par β€” parallel command processing πŸ¦‹


🌸 SYNOPSIS 🌸

rancid_par [-FHdefiqx] [-c command] [-l logfile] [-n #] [-p #] [file [file...]]

like... that's the whole shape of it. flags, then maybe some files. slay.


πŸ’… DESCRIPTION πŸ’…

so rancid_par takes a list of files and runs a command on them. that's the job. that's the assignment. πŸ‘‘

here's the tea tho β€” the first line of each file has to begin with either a colon (:) or a pound-sign (#). those are your two moods:

  • if it's a colon, then the rest of that first line is a command to run for each of the subsequent lines. like a lil template. ✨
  • if it's a pound-sign, then every subsequent line is its own self-contained command... unless you passed the -c option, in which case those lines become the arguments that replace the braces ({}s) in the -c argument. plot twist, but make it useful. πŸŽ€

oh and you can also feed the input file on stdin, in the exact same format as described above. same energy, different pipe.

and in every case where those lines after the first one are not commands (i.e. the colon case, or the -c case), instances of open-close braces ({}) in the command get replaced by those values. substitution, but make it fashion. πŸ’…

for example, an inputfile whose contents is:

: echo {}
a
b
c

run with rancid_par like so:

%rancid_par -q inputfile

will produce the following output (order will vary, bestie, don't come for me):

b
a
c
⚠️ note that "order will vary" thing. that's real. it's parallel, it's chaos, it's iconic. don't @ me when your output isn't alphabetical.

πŸŽ€ OPTIONS πŸŽ€

the command-line options are as follows, and yes we're doing all of them, no skipping, that's the rule:

  • -F β€” omit the footer that normally follows the output of each job. bye bye lil footer 🫢
  • -H β€” omit the header that normally precedes the output of each job. no header for you πŸ™ˆ
  • -c β€” the command to be run on each of the arguments following the command-line options, where the first line of the input file(s) begins with a pound-sign (#). πŸ“
  • -d β€” print debugging information on standard error (stderr). repeat the option up to three times for more verbosity. yes, you can stack it. go off. πŸ”₯
  • -e β€” split args by spaces, rather than using sh -c. > note: -e is incompatible with the -i option. so don't. 😭
  • -f β€” no input file or STDIN, just run a quantity of the command specified with -c. sometimes you just wanna run it, yk?
  • -i β€” run commands interactively through (multiple) xterm(1) processes. very main character. πŸ–₯️✨
  • -l β€” prefix of logfile name, as in prefix.N where N is the rancid_par process number ([0..]).
    • default: par.log.<time>.[0..]
  • -n N β€” number of simultaneous processes.
    • default: 3
  • -p N β€” pause N seconds between running commands. hydration break πŸ’§
  • -q β€” quiet mode. omit the typical processing logs and do not create the log files from -l; instead the children inherit stdout and stderr from rancid_par. > ⚠️ -q is mutually exclusive with the -x and -l options, and the option appearing last will take precedence. it's giving "last one to speak wins". πŸ’€
  • -x β€” view rancid_par logs in real-time via an xterm(1). live footage. πŸ“Ί

πŸ¦‹ FILES πŸ¦‹

  • par.log.T.N β€” log file; where T is the current time in seconds since the epoch and N is the rancid_par process number ([0..]). timestamped and numbered, as one does. πŸ•

🌈 HISTORY 🌈

so rancid_par was ported from the perl version. it differs in the following manner:

  1. if rancid_par receives a HUP/INT/TERM/QUIT signal, it does not print the commands that will not be run. no ghost commands, they just don't show up. πŸ‘»
  2. if rancid_par received a HUP/INT/TERM/QUIT signal, it does not exit immediately after sending kill to running jobs. it waits for them to exit so that they are cleaned-up properly. > if a second signal is received, it dies immediately. so like, the first one is a polite request and the second one is a "okay fine, bye". πŸ’€

okay bestie that's the whole page 🫢 you did it, you read the entire thing, we love that for you. this was rancid_par(1) from the General Commands Manual, dated 29 July 2019 β€” mwah, iconic, periodt. πŸ’–βœ¨πŸŽ€πŸ¦‹