bin/65299: vi(1) temp path contains double /
samb at catalyst.net.nz
samb at catalyst.net.nz
Mon Jun 23 05:00:18 UTC 2008
The following reply was made to PR bin/65299; it has been noted by GNATS.
From: samb at catalyst.net.nz
To: bug-followup at FreeBSD.org,
mharo at freebsd.org
Cc:
Subject: Re: bin/65299: vi(1) temp path contains double /
Date: Mon, 23 Jun 2008 16:54:33 +1200 (NZST)
------=_20080623165433_94784
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
I don't see this causing a problem myself because it appears you can add
as many directory separators as you want without problem.
The _PATH_TMP value is being pulled from /usr/include/paths.h which is
defined as /tmp/. vi is then adding a second / onto it.
The attached patch will not insert an extra / if it's not needed.
If for example _PATH_TMP was defined as /tmp///, it would only drop the
trailing / and would come out as /tmp//vi.XXXXXXXXXX. It could easily
enough be modified so there's only a single / between _PATH_TMP and
vi.XXXXXXXXXX but it seems like it could be a bit overkill for pretty much
an entirely aesthetical change. Any thoughts on this?
------=_20080623165433_94784
Content-Type: text/plain; name="exf.c.patch.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="exf.c.patch.txt"
Index: contrib/nvi/common/exf.c
===================================================================
--- contrib/nvi/common/exf.c (revision 179865)
+++ contrib/nvi/common/exf.c (working copy)
@@ -189,8 +189,14 @@
if (LF_ISSET(FS_OPENERR) || oname == NULL || !exists) {
if (opts_empty(sp, O_DIRECTORY, 0))
goto err;
- (void)snprintf(tname, sizeof(tname),
- "%s/vi.XXXXXXXXXX", O_STR(sp, O_DIRECTORY));
+
+ strncpy(&tname, O_STR(sp, O_DIRECTORY), sizeof(tname));
+
+ (void)snprintf(tname, sizeof(tname),
+ tname[strlen(tname)-1] == '/'
+ ? "%svi.XXXXXXXXXX" : "%s/vi.XXXXXXXXXX",
+ O_STR(sp, O_DIRECTORY));
+
if ((fd = mkstemp(tname)) == -1) {
msgq(sp, M_SYSERR,
"237|Unable to create temporary file");
------=_20080623165433_94784--
More information about the freebsd-bugs
mailing list