Bash: assigning the output of 'times' builtin to a variable - bash

Question

In a bash script I would like to assign the output of the times builtin to an array variable, but I found no better way than
tempnam=/tmp/aaa_$$_$RANDOM
times > ${tempnam}
mapfile -t times_a < ${tempnam}
I write the output to a temp file and read it back in array times_a because pipelines or $(times) would execute in a subshell and return the wrong values.
Any better solution without the temp file?

Answer 1

The fundamental problem that you need to solve is how to get both the execution of time and the variable assignment to happen in the same shell, without a temporary file. Almost every method Bash provides of piping the output of one thing to another, or capturing the output of a command, has one side working in a subshell.
Here is one way you can do it without a temporary file, but I'll warn you, it's not pretty, it's not portable to other shells, and it requires at least Bash 4:
coproc co { cat; }; times 1>&${co[1]}; eval "exec ${co[1]}>&-"; mapfile -tu ${co[0]} times_a
I'll break this down for you:
coproc co { cat; }
This creates a coprocess; a process which runs in the background, but you are given pipes to talk to its standard input and standard output, which are the FDs ${co[0]} (standard out of cat) and ${co[1]} (standard in of cat). The commands are executed in a subshell, so we can't do either of our goals in there (running times or reading into a variable), but we can use cat to simply pass the input through to the output, and then use that pipe to talk to times and mapfile in the current shell.
times >&${co[1]};
Run times, redirecting its standard out to the standard in of the cat command.
eval "exec ${co[1]}>&-"
Close the input end of the cat command. If we don't do this, cat will continue waiting for input, keeping its output open, and mapfile will continue waiting for that, causing your shell to hang. exec, when passed no commands, simply applies its redirections to the current shell; redirecting to - closes an FD. We need to use eval because Bash seems to have trouble with exec ${co[1]}>&-, interpreting the FD as the command instead of part of the redirection; using eval allows that variable to be substituted first, and then then executed.
mapfile -tu ${co[0]} times_a
Finally we actually read the data from the standard out of the coprocess. We've managed to run both the times and the mapfile command in this shell, and used no temporary files, though we did use a temporary process as a pipeline between the two commands.
Note that this has a subtle race. If you execute these commands one by one, instead of all as one command, the last one fails; because when you close cats standard in, it exits, causing the coprocess to exit and FDs to be closed. It appears that when executed all on one line, mapfile is executed quickly enough that the coprocess is still open when it runs, and thus it can read from the pipe; but I may be getting lucky. I haven't figured out a good way around this.
All told, it's much simpler just to write out the temp file. I would use mktemp to generate a filename, and if you're in a script, add a trap to ensure that you clean up your tempfile before exiting:
tempnam=$(mktemp)
trap "rm '$tempnam'" EXIT
times > ${tempnam}
mapfile -t times_a < ${tempnam}

Answer 2

Brian's answer got me very interested in this problem, leading to this solution which has no race condition:
coproc cat;
times >&${COPROC[1]};
{
exec {COPROC[1]}>&-;
mapfile -t times_a;
} <&${COPROC[0]};
This is quite similar in underlying structure to Brian's solution, but there are some key differences that ensure no funny-business occurs due to timing issues. As Brian stated, his solution typically works because the bash interpreter starts running the mapfile command before the coprocess' file descriptors have been fully closed and cleaned up, so any unexpected delay before or during mapfile would break it.
Essentially, the coprocess' stdout file descriptor gets closed a moment after we close the coprocess' stdin file descriptor. We need a way to preserve the coprocess' stdout.
In the man pages for pipe, we find:
If all file descriptors referring to the read end of a pipe have been closed, then a write(2) will cause a SIGPIPE signal to be generated for the calling process.
Thus, we must preserve at least one file descriptor to the coprocess' stdout. This is easy enough to accomplish with Redirections. We can do something like exec 3<&${COPROC[0]}- to move the coprocess' stdout file descriptor to a newly created fd 31. When the coprocess terminates, we will still have a file descriptor for its stdout and be able to read from it.
Now, we can do the following:
Create a coprocess that does nothing but cat.
coproc cat;
Redirect times's stdout to the coprocess' stdin.
times >&${COPROC[1]};
Get a temporary copy of the coprocess' stdout file descriptor.
Close the coprocess' stdin file descriptor. (If using a version before Bash-4.3, you can use the eval trick Brian used.)
exec 3<&${COPROC[0]} {COPROC[1]}>&-;
Read from our temporary file descriptor into a variable.
mapfile -tu 3 times_a;
Close our temporary file descriptor (not necessary, but good practice).
exec 3<&-;
And we're done! However, we still have some opportunities to restructure to make things neater. Thanks to the nature of redirection syntax, this code:
coproc cat;
times >&${COPROC[1]};
exec 3<&${COPROC[0]} {COPROC[1]}>&-;
mapfile -tu 3 times_a;
exec 3<&-;
behaves identically to this code:
coproc cat;
times >&${COPROC[1]};
{
exec {COPROC[1]}>&-;
mapfile -tu 3 times_a;
} 3<&${COPROC[0]};
From here, we can remove the temporary file descriptor altogether, leading to our solution:
Bash 4.3+:
coproc cat; times >&${COPROC[1]}; { exec {COPROC[1]}>&-; mapfile -t times_a; } <&${COPROC[0]}
Bash 4.0+:
coproc cat; times >&${COPROC[1]}; { eval "exec ${COPROC[1]}>&-"; mapfile -t times_a; } <&${COPROC[0]}
1We do not need to close the original file descriptor here, and can just duplicate it, as the original gets closed when the stdin descriptor gets closed

Answer 3

Wow, good question.
An improvment would be to use mktemp, so that you are not relying on randomness to keep your file unique.
TMPFILE=$(mktemp aaa_XXXXXXXXXX)
times > "$TMPFILE"
mapfile -t times_a < ${tempnam}
rm "$TMPFILE"
Also, I use for instead of mapfile (becuase I don't have mapfile).
a=0; for var in $(cat "$TMPFILE"); do ((a++)); TIMES_A[$a]=$var; done
But, yeah, I do not see how you can do it without files or named pipes.

Answer 4

One possibility to do something similar would be
times > >(other_command)
It's an output redirection combided with a process substitution. This way times is executed in the current shell and the output redirected to a new subprocess. Therefore however doing this with mapfile doesn't make much sense, as that command wouldn't be executed in the same shell, and that's probably not what you'll want. The situation is a bit tricky, as you can't have either call to the shell builtins executed in a subshell.