bug#6330: Feature request: mktemp creates named pipes

[Sebastien Andre]

On Wed, Jun 2, 2010 at 6:14 PM, Eric Blake <address@hidden> wrote:

> On 06/02/2010 04:08 AM, Sebastien Andre wrote:
> > Hello guys!
> >
> > When needing a temporary named pipe in shell scripts, I've often been
> > writing the following function:
> >
> > mktempfifo() {
> >     local path=$(mktemp -t)
> >     rm "$path"
> >     mkfifo -m 0600 "$path"
> >     echo "$path"
> > }
>
> First off, thanks for the suggestion.
>
> What's wrong with the example given in the manual (info coreutils
> mktemp), as adjusted to your usage pattern:
>
> mktempfifo() {
>    local dir
>    dir=$(mktemp -t -d) || return 1
>    mkfifo -m 0600 "$dir/fifo" || return 1
>    echo "$dir/fifo"
> }
>
> other than the fact that you have to remember to also remove the
> temporary directory?  And if you need to create more than one secure
> temporary object, it becomes a much easier paradigm to create a single
> secure directory in which to place all the other objects, and use a
> simple 'rm -rf "$tmpdir"' in your cleanup paths.  That's how coreutils
> 'make check' works - every test is run inside its own temporary
> directory, and within the body of the test, there is no need to worry
> about name collisions from external processes.
>
> >
> > I was wondering if anybody would be interested in having an option -p
> --pipe
> > (or -f --fifo since -p is deprecated)
> > to create temporary named pipes?
>
> You are correct that a short option -p cannot be used.  And I'm
> reluctant to burn -f unless there is another implementation that already
> does it.  But you have a point that adding a long option --fifo may make
> sense.  However, I thought about that same point the last time I touched
> mktemp(1), and did not implement it at that time because I felt that a
> temporary directory was enough.  But I can be swayed if you can present
> good arguments why the addition is better than using existing tools.
>
>
Thank you Eric for your answer,

I see two reasons why the addition of a --fifo option is better than using
existing tools:

    * Creating a temporary directory to finally create a pipe just because
it is safe this way is kind of a trick. For the clarity of scripts, it would
be better having mktemp to ensure the uniqueness of a fifo, even if it's
created in /

    * mktemp is not only a tool to create unique files, it's also a name
generator. The example given in the manual works for one or two fifos, but
if the number of fifos is unknown there is no choice but implementing
something to generate names, which is another potential source of bugs.


Below is an example of two functions using temp fifos, with and without the
-f option (code not tested):


# merge the output of every given command, line by line (fifos are not
removed for clarity)

merge_output_mktempfifo() {
    local fifos=()
    if [ $# -gt 0 ]; then
        for cmd in "$@"; do
            local fifo=$(mktemp -tf) || return 1
            ( $cmd > $fifo ) &
            fifos=( address@hidden $fifo )
        done
        paste "address@hidden"
       wait
    fi
}

merge_output_traditional() {
    local tmpdir=$(mktemp -td) || return 1
    local i=0
    if [ $# -gt 0 ]; then
        for cmd in "$@"; do
            i=$(expr $i + 1)
            mkfifo -m 0600 "$tmpdir/fifo$i"
            ( $cmd > "$tmpdir/fifo$i" ) &
        done
        paste $tmpdir/fifo*
        wait
    fi
}

The merge_output_traditional() function is more difficult to understand than
merge_output_mktempfifo() because of the use
of $i to ensure unicity of fifo names. If for any reason $tmpdir must be
shared with other processes which use the exact same function it will
lead to a mess, that's why I prefer merge_output_mktempfifo().

I think the "traditional way" to deal with named fifos is good and efficient
but tricky. The -f option would be more straightforward.

>
> > PS: I can try to provide a patch if my bug is accepted
>
> Patches speak volumes, although by the time you add the code and the
> documentation, your contribution would probably be non-trivial and
> require copyright assignment to the FSF.  Let us know if you'd like to
> start that process.
>
>
Yes, I'm interested in starting that process.




>  --
> Eric Blake   address@hidden    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
>