redo 1 user commands redo redo rebuild utility redo --silent --debug --keep-going --verbose --jobs number --directory dirname filename(s) redo unconditionally attempts to rebuild the list of targets given as filenames. It does this by executing a .do program, that is expected both to build each target, and at the same time record what dependencies should cause the target to be rebuilt if given as a target to redo-ifchange1. .do programs can invoke redo-ifchange1, which may recursively cause dependencies to have their .do programs invoked. redo uses the same jobserver mechanism as used by the GNU and BSD make1 programs, whereby multiple parts of a build can run in parallel. If the --jobs command-line option is used, and if there is not already a jobserver set up by a parent process, it sets up a jobserver pipe with number job slots. It then attempts to execute as many .do programs in parallel as it can procure job slots for. The distribution of jobs, down the build tree, is thus determined by whether .do programs recursively invoke redo-ifchange1 with one dependency or many. If there is a jobserver already set up, redo assumes that a job slot has already been procured for it, given that it is running. Similarly, if there is no jobserver and it is not told to set up a jobserver, it acts as if there is a single, implicit, slot; behaving largely as if there were a 1-slot jobserver. It re-uses this implicit slot for the first .do program that it spawns, only procuring slots for additional parallel child processes. Thus if no additional slots are actually available, it devolves from the parallel down to the serial case. Importantly, it does not release its own implicit job slot back to the jobserver, and never devolves beyond the serial case to not being able to run jobs at all. The --directory command-line option causes redo to change directory to dirname before doing anything. The --keep-going command-line option causes it to attempt to build all targets, even if building one of them fails. The --verbose command-line option causes it to print more information about its processing. The --debug command-line option causes it to print debugging information about its internal operation. And the --silent command-line option causes it to print less information about its processing. redo has a two factor search for .do programs. Firstly, it searches for .do programs in a succession of directories, starting with the directory of the target and (if it does not have an absolute pathname) then checking each successively shorter path prefix until it ends with the current working directory. So if the target is a/b/c/d/e, it will check a/b/c/d/, then a/b/c/, then a/b/, then a/, and then finally . the current directory. For a target /a/b/c/d/e, on the other hand, it will only check /a/b/c/d/. Secondly, within each directory it searches for the .do program by looking for successively shorter extension suffixes taken from the target. To these it prepends the word default and the suffix .do. It also, before doing that, checks for the full target filename with .do appended. So if the target is dir/base.a.b, it will look for dir/base.a.b.do, dir/default.a.b.do, dir/default.b.do, dir/default.do, base.a.b.do, default.a.b.do, default.b.do, and default.do. A .do program can be any kind of executable, although conventionally it is a script. (redo does not force a choice of shell, and the script must therefore begin with a #! line that names the shell that the script is written for.) redo invokes the program with a REDOFLAGS environment variable, which it uses to pass option and target information to recursively executed instances of redo (possibly invoked indirectly via redo-ifchange1). .do programs should not alter, or inspect, the value of this variable. redo also invokes it with open file descriptors, indicating the jobserver pipe and where to record dependencies for the current target. .do programs should not close these file descriptors, and should not perform I/O on them other than with redo-ifchange1 and redo-ifcreate1. It sets the MAKELEVEL environment variable, which is used in messages to indicate the recursion depth. It invokes the program with three arguments: the directory prefix and base name of the target (e.g. dir/base.a) the extension part of the target that matched the default file (e.g. .b) the name of a temporary file where the target is to be built redo performs atomic builds of individual targets. A target is built to a temporary filename (in the same directory), and if and only if the .do program exits with a success status is that temporary filename atomically renamed to the actual target. redo version 1.0 came out in 2012. It switched from UTC time to to TAI64N in 2026. Jonathan de Boyne Pollard