As one of the proponents of the change, my apologies for not taking
part in this thread earlier - I am way behind in my reading of most of
the lists.

On Thu, Jun 08, 2000 at 11:11:42AM +1000, Kris Kennaway wrote:
>Instead of using only alphabetic characters, the patch uses the following
>character set:

This was discussed in -audit as well - and most of the points brought
up here have already been discussed there.

> Peter, I hope I've got the right version of the patch

Looks about right.  The character set matches my last suggestion (the
only other item was making base64 and padchar `const').

On Thu, Jun 08, 2000 at 04:08:18PM +1000, Matthew Dillon wrote:
>    It would be a good idea to avoid any punctuation.

Could you please provide some rationale for this statement.  I agree
there are valid reasons for not using some specific characters, but I
don't see any justification for a blanket ban.

On Fri, Jun 09, 2000 at 04:15:45AM +1000, Garance A Drosihn wrote:
>context that reads blah@blah:blah as userid@hostname:fname

Good point.  I hadn't considered the impact of letting [rs]cp
loose on the output from mktemp.

>At the same time, I do like to see the set expanded as much as
>possible, without causing any problems.

That was my rationale as well.  I went through the 7-bit printable set
and wiped out the characters I though would cause problems.

On Thu, Jun 08, 2000 at 09:51:34PM +1000, Bruce Evans wrote:
>Why are we still using the pid?  It is highly non-random.  It was
>originally used to ensure a separate starting point for separate

The other advantage is that it was easy to locate and delete temp
files associated with dead processes.  Given the change to a BASE64
PID, this is no longer true and I agree with Kris that it can be
dropped.  If you need to clean up after dead processes, you'll need
to use lsof or fstat to work out what files are still wanted.

On Fri, Jun 09, 2000 at 01:48:20PM +1000, Kris Kennaway wrote:
>I'm not sure that weird filesystems are a valid argument against mktemp()
>naming - there are LOTS of UNIX code which assumes UNIX namespace
>conventions, and it's not just mktemp() which is going to break on weird
>filesystems. For example, should we limit all FreeBSD file names to 8.3
>single-case in case someone wants to run from an old-style MSDOS

I agree with Kris here.  I briefly considered the problem of support
for non-UFS filesystems and decided that it was reasonable for
standard Unix utilities to make use of the facilities offered by the
native filesystem - ie UFS.

In any case, I believe that mktemp(3) will always return a valid
filename for the filesystem (though it might take some time to pick
one).  _gettemp() [the function underlying mktemp(3), mkstemp(3) etc]
invokes lstat(2) on each sample path and requires that lstat() returns
ENOENT for it to succeed.  If lstat() is given an invalid pathname, it
should return something like EINVAL - which will make _gettemp() try
again.  If a filesystem implementation returns ENOENT when given a
pathname that is not valid on that filesystem, then the filesystem
implementation is broken and should be fixed.

Note that AFAIK, currently FreeBSD cannot meet mkstemp guarantees on
_any_ non-local filesystem (and some shared filesystem types) because
the relevant locking mechanisms either don't exist or don't work.

On Fri, Jun 09, 2000 at 02:57:02PM +1000, Garance A Drosihn wrote:
>Should the new mktemp check some kind of environment variable,
>and use a different list (or maybe even a totally different
>algorithm) depending on the value?

I think that selecting between a number of different algorithms based
on an environment variable might be over-kill.  However it could be
useful to allow the user to control the character set used by mktemp()
via an environment variable.  For example
would give you the POSIX portable filename character set (apart from
the `no leading hyphen' bit).  Maybe support two variables - one to
defines the allowable initial characters and another to define the
allowable following characters if it's different.

The downside is that this means that the user can pretty much control
the temporary filenames used by processes - which means it would need
to be disabled for setuid (and maybe setgid) processes.

On Fri, Jun 09, 2000 at 03:08:57PM +1000, Dan Nelson wrote:
>I still suggest not using symbols at all, since I'd like to be able to
>quickly remove tempfiles by hand without worrying if I have to escape #
>or ^, etc.  ...
>I'd rather stick with easy-to-read and type tempnames.

`easy-to-read and type' is basically incompatible with
`hard-to-guess'.  I'd suggest that most people will be deleting mktemp
filenames using wildcards, shell-completion or cut-and-paste.  Any
shell that can't understand a filename that it has globbed is broken.
Similarly, any shell that does shell completion without protecting
the result from $IFS or globbing is broken.  And if in doubt, you
can always paste between single quotes.

>mktemp() doesn't use TMPDIR; the user gets to pass a template of his
>choosing, which could reasonably be just "bobXXXXX.tmp".

To pick a nit: mktemp() doesn't allow suffixes, you need to use

On Sat, Jun 10, 2000 at 04:05:34PM +1000, Bruce Evans wrote:
>There is the POSIX.1 portable filename character set: [A-Za-z._-] (from
>which the hyphen shall not be used as the first character of a portable

I suspect that whilst POSIX guarantees that those characters can be
used in filenames, it does not guarantee that the names will refer to
distinct files.  Case-insensitive filesystems are fairly common - which
would reduce the effective set to [a-z._-] - which is ridiculous.

On Sun, Jun 11, 2000 at 02:41:12AM +1000, Daniel C. Sobral wrote:
>Mind you, shells don't have problems with any character at all in a
>filename if they are properly written, but if you are expecting the
>filenames generated by mktemp() to be handled by shell, they ought to
>pass the
>IFS=':'; for file in $filelist

Why?  Isn't it equally valid to state that they ought to pass
        IFS='a'; for file in $filelist
or setting IFS to any other random character?

On Mon, Jun 12, 2000 at 07:51:15AM +1000, David Scheidt wrote:
>  "@" is used as the line
>erase character in some shells.  "#" is rubout in some shells.

Generally very old shells that were designed on the assumption that
the user was sitting at a KSR33 or similar.  Does anyone using
FreeBSD have any stty cchars set to printable characters?  Do any
FreeBSD shells (including ports) default to using printable cchars?
I would be very surprised if the answer to either question was yes.

(Anyone who has erase=@ is either an expert at escaping it, or we
aren't going to hear from them because they won't be able to type
the mailing list address :-).

On Mon, Jun 12, 2000 at 08:39:44AM +1000, Peter Wemm wrote:
># is a comment

# shouldn't be treated as a comment in the output from command
substitution or in variable expansions.  There may be a problem
with evals.

>~ at the beginning is a ~username

Only at the beginning of a word and the proposed mktemp can't
generate ~ at the beginning of a word.

>^ is an alias for | in old shells

Yes, but not in any shells used on FreeBSD.

These points were all discussed in -audit.  


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to