bug#6330: Feature request: mktemp creates named pipes

[Jim Meyering]

Sebastien Andre wrote:

> On Sat, Jun 5, 2010 at 9:25 AM, Jim Meyering <address@hidden> wrote:
...
>     "because it is safe" is often a good reason to learn and use a new idiom.
>     When you first encounter such an idiom, it does indeed look like a 
> "trick".
>
> Well, after all an idiom might just be a "popular trick"

"Effective technique" is more accurate.
This is the "unix way".

>     >     * 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.
>
>     Any code addition is an opportunity to introduce bugs ;-)
>
>     What if someone wants a uniquely-named symlink?
>     New option?  ... or a shared memory object?  Add another?
>     Wouldn't it be better to use the tried and true (safe) idiom
>     that will work with all versions of mktemp?  Then
>     your script will work also on systems that use the
>     version of mktemp that predated the one in coreutils.
>
> Thank you for broadening the question.
>
> You made me realize that what I really want is to use the tempnam(3) function
> in shell scripts. But having a tempnam command in a shell script would be
> unsafe unless
> something is created atomically when invoked. If mktemp(1) is not the right
> place for this, how about adding a -t/--template option to the mkfifo(1) ?

And to mknod
and to ln?

> Wanting to get a unique name in a given directory according to a template
> doesn't sound too specific to me, maybe some other people need it?

If that given directory has only one writer, then using mktemp -u is fine.

Other people use mktemp -d, and then can create names however
they like (and safely) in the just-created directory.

The point that someone might want to create an object of a type other
than "fifo" (e.g., symlink, hard link, block dev., etc.) was to make
you think about adding a more generic option, but then you'd have to
consider how to specify the target of a symlink and major,minor numbers
for a block device.

I was hoping you would then conclude that this would lead to mktemp
subsuming most of the functionality of tools like ln, mkfifo and mknod,
and thus rethink your premise that it would be better to change mktemp
than to use it the way everyone else does.