On 08/23/2010 11:00 AM, Eric Blake wrote: [snip] > If we add 'mktemp --fifo', then where do we stop? What about creating a > uniquely named symlink? Or a new shared memory object?
There are several possible answers to "Where do we stop?". 1) Stop at current code [no changes.] 2) Stop when user requests stop. 3) Add --symlink and --hardlink. Each requires another string argument. Limiting the number of string arguments is a defensible argument: it is based on an extrinsic property. 4) Add --block and --character device nodes. Each requires two non-negative integer arguments, and mktemp should check this in order to provide good Usability. 5) Stop when all file types of S_IFMT (<stat.h>) have been covered. This would add S_IFSOCK, which is gnarly indeed. 6) Stop after shmem, which is not even a file type. I favor drawing the line between 2) and 3), which means adding --fifo and not the others. Two independent user requests [one of which includes code!] within a few months show a definite need. > 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'? The user of such a fifo must be taught that one unlink() or "rm -f fifo" does recover all the resources. That is a significant reduction in *each* of the five software metric dimensions: Functionality, Usability, Performance, Maintenance, and Supportability. The hard task is finding all the places that [should] remove objects from the filesystem, and teaching them to remove the directory of such a fifo, too. For shell, a dirname() must be applied. For C code, then the code must figure out [or be told] that the name is special, parse the name, and perform another unlink(). This is not trivial. > A couple kilobytes of disk > space for a temporary directory given today's storage technologies is > not a very convincing argument. One of the places where I want such fifos [many hundreds of them] is in a filesystem that resides on a much smaller flash memory device. Occupying a megabyte more than necessary can be fatal. > 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. It's not nice to get a compound object (directory plus fifo) when a singleton is expected, and when the compound object cannot be treated identically to the singleton. The properties are different, not "reproduced"; and that makes it not "bloat." --
