mktemp: add -p/--tmpdir argument
ClosedPublic
Actions

Authored by kevans on Oct 25 2022, 4:52 PM.

Details

Reviewers

bapt
emaste
wosch
imp

Group Reviewers

Klara

Commits

rGac6f924e1cd1: mktemp: add -p/--tmpdir argument

Summary

This matches other mktemp implementations, including OpenBSD and GNU.
The -p option can be used to provide a tmpdir prefix for specified
templates. Precedence works out like so:

-t flag:

$TMPDIR
-p directory
/tmp

Implied -t flag (no arguments or only -d flag):

-p directory
$TMPDIR
/tmp

Some tests have been added for mktemp(1) in the process.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 48049
Build 44936: arc lint + arc unit

Event Timeline

kevans created this revision.Oct 25 2022, 4:52 PM

Herald added a subscriber: imp. · View Herald TranscriptOct 25 2022, 4:52 PM

kevans requested review of this revision.Oct 25 2022, 4:52 PM

kevans added a parent revision: D37120: mktemp: add some GNU-compatible long options.

Harbormaster completed remote builds in B47990: Diff 112192.Oct 25 2022, 4:53 PM

imp accepted this revision.Oct 25 2022, 5:19 PM

This revision is now accepted and ready to land.Oct 25 2022, 5:19 PM

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

In D37121#843436, @wosch wrote:

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

I was previously synced to rGed5e7fb16c by mistake, but I rebased this branch to rG866beaa0aa9 and it still builds OK here -- what does the failure look like?

In D37121#843438, @kevans wrote:

In D37121#843436, @wosch wrote:

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

I was previously synced to rGed5e7fb16c by mistake, but I rebased this branch to rG866beaa0aa9 and it still builds OK here -- what does the failure look like?

curl -L -o diff 'https://reviews.freebsd.org/D37121?download=true'

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100 8388 0 8388 0 0 13312 0 --:--:-- --:--:-- --:--:-- 721k
wosch@cloud2.dev <06:08:21> 14.0-CURRENT [~/projects/src] 508
bash$ patch -p1 < diff
Hmm... Looks like a unified diff to me...

The text leading up to this was:

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist

--- a/etc/mtree/BSD.tests.dist

+++ b/etc/mtree/BSD.tests.dist

Patching file etc/mtree/BSD.tests.dist using Plan A...
Hunk #1 succeeded at 1060 (offset 2 lines).
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/Makefile b/usr.bin/mktemp/Makefile

--- a/usr.bin/mktemp/Makefile

+++ b/usr.bin/mktemp/Makefile

Patching file usr.bin/mktemp/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.1 b/usr.bin/mktemp/mktemp.1

--- a/usr.bin/mktemp/mktemp.1

+++ b/usr.bin/mktemp/mktemp.1

Patching file usr.bin/mktemp/mktemp.1 using Plan A...
Hunk #1 succeeded at 37.
Hunk #2 succeeded at 93.
Hunk #3 failed at 146.
1 out of 3 hunks failed--saving rejects to usr.bin/mktemp/mktemp.1.rej
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.c b/usr.bin/mktemp/mktemp.c

--- a/usr.bin/mktemp/mktemp.c

+++ b/usr.bin/mktemp/mktemp.c

Patching file usr.bin/mktemp/mktemp.c using Plan A...
Hunk #1 succeeded at 38 with fuzz 2 (offset -1 lines).
Hunk #2 failed at 53.
Hunk #3 failed at 63.
Hunk #4 succeeded at 103 (offset -7 lines).
Hunk #5 succeeded at 145 (offset -1 lines).
Hunk #6 succeeded at 183 (offset -7 lines).
2 out of 6 hunks failed--saving rejects to usr.bin/mktemp/mktemp.c.rej

In D37121#843439, @wosch wrote:
In D37121#843438, @kevans wrote:

In D37121#843436, @wosch wrote:

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

I was previously synced to rGed5e7fb16c by mistake, but I rebased this branch to rG866beaa0aa9 and it still builds OK here -- what does the failure look like?

curl -L -o diff 'https://reviews.freebsd.org/D37121?download=true'
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 8388 0 8388 0 0 13312 0 --:--:-- --:--:-- --:--:-- 721k
wosch@cloud2.dev <06:08:21> 14.0-CURRENT [~/projects/src] 508
bash$ patch -p1 < diff
Hmm... Looks like a unified diff to me...

The text leading up to this was:

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist

--- a/etc/mtree/BSD.tests.dist

+++ b/etc/mtree/BSD.tests.dist

Patching file etc/mtree/BSD.tests.dist using Plan A...
Hunk #1 succeeded at 1060 (offset 2 lines).
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/Makefile b/usr.bin/mktemp/Makefile

--- a/usr.bin/mktemp/Makefile

+++ b/usr.bin/mktemp/Makefile

Patching file usr.bin/mktemp/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.1 b/usr.bin/mktemp/mktemp.1

--- a/usr.bin/mktemp/mktemp.1

+++ b/usr.bin/mktemp/mktemp.1

Patching file usr.bin/mktemp/mktemp.1 using Plan A...
Hunk #1 succeeded at 37.
Hunk #2 succeeded at 93.
Hunk #3 failed at 146.
1 out of 3 hunks failed--saving rejects to usr.bin/mktemp/mktemp.1.rej
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.c b/usr.bin/mktemp/mktemp.c

--- a/usr.bin/mktemp/mktemp.c

+++ b/usr.bin/mktemp/mktemp.c

Patching file usr.bin/mktemp/mktemp.c using Plan A...
Hunk #1 succeeded at 38 with fuzz 2 (offset -1 lines).
Hunk #2 failed at 53.
Hunk #3 failed at 63.
Hunk #4 succeeded at 103 (offset -7 lines).
Hunk #5 succeeded at 145 (offset -1 lines).
Hunk #6 succeeded at 183 (offset -7 lines).
2 out of 6 hunks failed--saving rejects to usr.bin/mktemp/mktemp.c.rej

Ah, sorry, it builds on top of the earlier patch in the stack: https://reviews.freebsd.org/D37120 ("mktemp: add some GNU-compatible long options")

On debian11 I get for the empty string value for -p

mktemp -p "" -t foo.XXX
/tmp/foo.nx3

on FreeBSD I get with this patch
/usr/obj/usr/home/projects/freebsd-src/amd64.amd64/usr.bin/mktemp/mktemp -p "" -t foo.XXX
mktemp: mkstemp failed on /foo.XXX.emdJPzzhW7: Permission denied

In mktemp.c:86 is a check for NULL, but not for the empty string. I wish we could be compatible with debian.

This revision now requires changes to proceed.Oct 27 2022, 6:36 AM

Empty -p flag should be treated the same as an omitted --tmpdir to actually be
compatible; fixed this omission, updated the manpage appropriately and added
a test for that specific scenario.

Harbormaster completed remote builds in B48049: Diff 112286.Oct 27 2022, 3:30 PM

wosch accepted this revision.Oct 27 2022, 8:37 PM

This revision is now accepted and ready to land.Oct 27 2022, 8:37 PM

Closed by commit rGac6f924e1cd1: mktemp: add -p/--tmpdir argument (authored by kevans). · Explain WhyOct 31 2022, 3:56 AM

This revision was automatically updated to reflect the committed changes.

kevans added a commit: rGac6f924e1cd1: mktemp: add -p/--tmpdir argument.