bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6900: mktemp: want option to make a fifo


From: Eric Blake
Subject: bug#6900: mktemp: want option to make a fifo
Date: Mon, 23 Aug 2010 12:00:50 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

On 08/23/2010 11:34 AM, John Reiser wrote:
On 08/23/2010 09:40 AM, Eric Blake wrote:
On 08/23/2010 09:22 AM, John Reiser wrote:
mktemp: Please add an option which creates a fifo
   [snip]

Thanks for the report.  However, I'm inclined to mark this bug as a
duplicate of 6330, for the reasons already documented in this long thread:
http://lists.gnu.org/archive/html/bug-coreutils/2010-06/msg00013.html

The suggested alternative (use "mktemp -d" to create a uniquely-named
directory, then use mkfifo of an arbitrary fixed name within that directory)
satisfies only some of the desired properties.  Yes, it's a fifo with
a safely-created unique name.  However, removing that fifo leaves behind
the directory, and the directory also occupies its own space [often
a few kilobytes] even during the lifetime of the fifo.

If we add 'mktemp --fifo', then where do we stop? What about creating a uniquely named symlink? Or a new shared memory object?

http://lists.gnu.org/archive/html/bug-coreutils/2010-06/msg00033.html

And did you not read in that thread about the arguments that recursively moving an entire temporary directory hierarchy with 'rm -rf dir' is just as short in shell code as 'rm -f fifo'? A couple kilobytes of disk space for a temporary directory given today's storage technologies is not a very convincing argument.

The whole argument of Unix is that each tool does one thing well, so that the combination of tools can do everything. mktemp should NOT be bloated just to reproduce the functionality of mkfifo or of ln, when those tools can already be paired nicely.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]