Hacker News Reader

Comment by chousuke | Hacker News Reader

Can mktemp fail? I recently wrote a script that ensures that the directory created by mktemp actually exists and starts with /tmp so that when the script wipes out its temporary data at the end, it will not ever run something like "rm -rf /". Using fully-qualified paths for everything is also (not) fun.

In another script I was leery about running rm -f -- /path/foo* so I instead used

  find /path -mindepth 1 -maxdepth 1 -name "foo*" -delete

because then the glob can't affect find's behaviour in weird ways.

Most likely set -e is enough protection against mktemp failing and the rm -f glob probably would've been just fine, but shell scripting has enough footguns that sometimes I can't help but go overboard with paranoia.

View on HN

Yes, mktemp can fail.

For example, "TMPDIR=/dev/null mktemp -d" will reliably fail.

You shouldn't be validating it starts with "/tmp" though, because on quite a few systems, people set TMPDIR=/var/tmp.

You absolutely should check if mktemp exited nonzero, but if it exited 0, the directory should be safe to use. If you want to be really paranoid, you can check if the output is an empty string too after checking the exit code.

I think you're shying a little too far away from bash's globbing. Yeah, bash has footguns, but using clever workarounds can also be a recipe for creating confusing and error prone code in its own way.

Please tell me it's enough to check the exit code! That's all I ever do and I have hundreds of mktemp scripts out there.

In the end I think shelling is mostly about controlling your inputs.

Not just inputs, unfortunately. TOCTOUs (and races in general), for instance, are very common problem in shell scripts.

Races and TOCTOUs are generally common problems in most concurrent systems that are not considering atomicity by design (e.g. rdbms). It's just that shell can very easily become concurrent...

Yes, it's enough to check the exit code. The parent poster's being overly paranoid.

The only thing that checking the exit code won't catch is bugs in mktemp/bash, or bad memory / solar flare bitflips.

> Can mktemp fail?

Yes it can. You should use its exit status (or set -e). See http://man.openbsd.org/mktemp

Note that there is a nasty trap if you're using local to declare and set a variable:

    a () { local M=`ls /asdf` && echo y; }
    b () {       N=`ls /asdf` && echo y; }
    a ; b ;

One will print y, the other will not.

Shellcheck helpfully warns about declaring and assigning in the same statement exactly because it masks exit status.

The point of mktemp is to use the right location on the current system, which may not be /tmp. If you're going to enforce that tmpdir must be /tmp, you might as well not bother with mktemp and just directly create a file or directory in /tmp.

With the "--" and assuming GNU rm, rm -f -- /path/foo* is safe. If you use a glob pattern that does not match itself, then you will want nullglob:

  rm foo.[cC]

will remove a file named literally foo.[Cc] if neither foo.c nor foo.C exist, despite the fact that foo.[Cc] does not match the glob. nullglob is probably a good default for bashscripts, but I don't think it exists in posix.

Wouldn't the glob still have issues with files that contain spaces?

My defensiveness generally takes a sharp upturn when I write scripts that will be run as root or ones that delete data, but I'll admit not trusting mktemp's exit code is probably taking it a bit too far.

globs have no issues with spaces.

glob expansions don't have issues with spaces. the shell just patches every full match as its own entry in the argument array.

Reply on news.ycombinator.com