Page MenuHomeFreeBSD

mktemp: add -p/--tmpdir argument
ClosedPublic

Authored by kevans on Oct 25 2022, 4:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 22, 1:47 PM
Unknown Object (File)
Fri, Mar 22, 12:30 PM
Unknown Object (File)
Tue, Mar 5, 3:00 PM
Unknown Object (File)
Jan 19 2024, 7:39 PM
Unknown Object (File)
Dec 23 2023, 5:27 AM
Unknown Object (File)
Dec 20 2023, 8:05 AM
Unknown Object (File)
Dec 12 2023, 2:33 AM
Unknown Object (File)
Dec 8 2023, 9:58 PM
Subscribers

Details

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.

Sponsored by: Klara, Inc.

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

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?

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?

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

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")

wosch requested changes to this revision.Oct 27 2022, 6:36 AM

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.

This revision is now accepted and ready to land.Oct 27 2022, 8:37 PM
This revision was automatically updated to reflect the committed changes.