1

I try to understand Stephen Kitt's answer to this question where he created a temporary directory with the following code:

#!/bin/bash

scripttmp=$(mktemp -d) # Create a temporary directory (these will usually be created under /tmp or /var/tmp/)

Each time I run this command I see a new temporary directory created under /tmp/ (I didn't know it will appear there until reading Roaima's answer here):

IIUC, there is no programmatical difference between a regular directory to a temporary directory (the only difference is in how these directories are used, by means of the time each one stays on the machine).

If there is no programmatical difference, why should one prefer mktemp -d over the more minimal mkdir?

  • I think the answer to this question on Stack Overflow explains it very well. Basically, you want to use mktemp when added security matters. – Mr Shunz Sep 26 '18 at 13:24
  • @JohnDoea, I found mktemp -d easier to use. – prosti Sep 26 '18 at 19:09
6

When using mkdir, the script would have to make sure that it creates a directory with a name that does not already exist. It would be an error to use mkdir dirname if dirname is an existing name in the current directory.

When creating a temporary directory (i.e. a directory that is not needed much longer than during the lifetime of the current script), the name of the directory is not generally important, and mktemp -d will find a name that is not already taken by something else.

mktemp -d makes it easier and more secure to create a temporary directory. Without mktemp -d, one would have to try to mkdir with several names until one succeeded. This is both unnecessarily complicated and can be done wrongly (possibly introducing subtle race conditions in the code).

mktemp also gives the user of the script a bit of control in where they want the temporary directory to be created. If the script, for example, produces a massive amount of temporary data that has to be stored in that directory, the user may set the TMPDIR environment variable (before or as they are invoking the script) to point to a writable directory on a partition where there is enough space available. mktemp -d would then create the temporary directory beneath that path.

If TMPDIR is not set, mktemp will use /tmp in its place.

| improve this answer | |
  • Also note that mktemp makes sure the directories are private (as if using (umask "$((0$(umask) | 077))"; mkdir -- "$tmpdir")) – Stéphane Chazelas Sep 26 '18 at 21:10
0

The thing with mktemp -d since it creates a temporary directory with a random name is: You need to remember to delete the directory after using it, if you have a strict temp directory deleting policy.

This is why you wrote scripttmp=$(mktemp -d) to hold the value. In general it is easy to use.

Unless you don't care, you may use this little example to generate the random name and remove the folder later:

var=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1);
mkdir "/tmp/$var"
#some code
rm -rf "/tmp/$var"

Is there a programmatical difference between directories created with mktemp -d or mkdir?

Well there is. With mkdir you generate the directory name, and with mktemp -d the system creates the directory for you based on /dev/urandom gettimeofday, getpid, ... and other functions to gain the name uniqueness.

| improve this answer | |
  • Something like dirname=$(head -c15 /dev/urandom | base64 | tr / _) would be shorter and more effective. But mktemp does the randomization for you anyway, so is there any reason to do it manually? If you have a policy on deleting temporary directories, you'll still have to delete the manually-randomized temporary directory. – ilkkachu Sep 26 '18 at 20:05
  • @ilkkachu, there is no question: mktemp -d is neat. Manual creating a directory name is an option, and I like when I have multiple options so I can learn about things. Your wrapper is just great, if you don't care about the + character which is OK as well. – prosti Sep 27 '18 at 9:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy