On 8/22/16 Aug 22 -4:00 PM, Elias Pipping wrote:

...

On 22 Aug 2016, at 22:47, Robert Goldman <rpgoldman@sift.net> wrote:

ACL offers a functionality like this with its make-temp-file-name and make temp file.

I'd love to have a portable version that would, for example, make temporary files that could be used as arguments in RUN-PROGRAM.

Is there any reason this could not be exported?

Dear Robert,

get-temporary-file is just an a very simple wrapper around with-temporary-file, which is already exported. What you can e.g. already do(*) is use

(with-temporary-file … (%run-program :output … :wait t))

or

(with-temporary-file (… :keep t) (%run-program :output … :wait nil))

That’s a pretty nice interface, I find (the implementation is another matter). Do you find it too verbose?

I am translating some existing code that does something like the following: concatenate f1 and f2 > temp file 1 concatenate f2 and f1 (i.e., reverse concat) > temp file 2 compute function of temp file 1 compute function of temp file 2 return minimum of f(temp file1), f(temp file2) I did this using "cat" for which it is more convenient to have the name of the file than the stream. In general, when invoking the shell, the shell "speaks" names, not CL streams. Now, as you said, I could simply replicate the logic of GET-TEMPORARY-FILE, but since GET-TEMPORARY-FILE pretty much replicates the interface of mktemp, which the shell wizards consider to be valuable, I think there's precedent for something like GET-TEMPORARY-FILE being supplied. Although, perhaps calling it GET-TEMPORARY-FILENAME would be better. Is there some reason it would be inappropriate to export this? Best, r

On Mon, Aug 22, 2016 at 5:48 PM, Robert Goldman <rpgoldman@sift.net> wrote:

I am translating some existing code that does something like the following:

concatenate f1 and f2 > temp file 1 concatenate f2 and f1 (i.e., reverse concat) > temp file 2 compute function of temp file 1 compute function of temp file 2 return minimum of f(temp file1), f(temp file2)

I did this using "cat" for which it is more convenient to have the name of the file than the stream.

In general, when invoking the shell, the shell "speaks" names, not CL streams.

Now, as you said, I could simply replicate the logic of GET-TEMPORARY-FILE, but since GET-TEMPORARY-FILE pretty much replicates the interface of mktemp, which the shell wizards consider to be valuable, I think there's precedent for something like GET-TEMPORARY-FILE being supplied. Although, perhaps calling it GET-TEMPORARY-FILENAME would be better.

Is there some reason it would be inappropriate to export this?

It's an unintentional omission indeed that UIOP/STREAM::GET-TEMPORARY-FILE wasn't exported. I thought I had exported it, but I failed to. The function has existed since 3.1.2 (i.e. the first stable 3.1 release). Note that in most cases, you'll have cleaner code using WITH-TEMPORARY-FILE, though (also to be considered debugged since 3.1.2). Note that for security reasons, a better (but non-portable) solution would be instead be using mkstemps or mkostemps. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When a pamphlet was published entitled "100 Authors Against Einstein", Einstein retorted "If I were wrong, one would be enough."

...

: Faré : rpg

...

It's an unintentional omission indeed that UIOP/STREAM::GET-TEMPORARY-FILE wasn't exported. I thought I had exported it, but I failed to. The function has existed since 3.1.2 (i.e. the first stable 3.1 release).

Since it has never been exported, I believe we can safely rename it. I note, actually, that my proposed renaming is also wrong. It should be

GET-TEMPORARY-PATHNAME not FILENAME, right? Since we get back a CL pathname and not a namestring. At the expense of a slightly fatter interface, I'm tempted to add both:

GET-TEMPORARY-PATHNAME returning a pathname and GET-TEMPORARY-FILENAME returning a filename (string)

I'm not opposed to renaming, but for some context, the get-temporary-file was meant to contrast with a (hypothetical) get-temporary-directory, just like mktemp and mkdtemp are related. I never implemented the get-temporary-directory variant, because (1) the use case didn't appear in asdf itself, (2) the function wasn't present in the other lisp libraries I wanted to obsolete, and (3) the absence of proper umask treatment by the Lisp variants. Ideally, the Lisp variants would rely on mkostemps and mkdtemp and similar interfaces, instead of reinventing the wheel, badly. Unhappily, reinventing the wheel badly is all that we're allowed in UIOP. For better portable interfaces, there is IOLib, but it requires linking to a C library and various functions may or may not be supported on Windows.

The former is more natural for CL, but the latter is more useful when interacting with anything that is not CL.

...

Note that in most cases, you'll have cleaner code using WITH-TEMPORARY-FILE, though (also to be considered debugged since 3.1.2).

Yes, I agree. For interop with the shell, though, this API may be handier.

As for pathname vs filename, I would use -namestring instead of -filename; and then again, if it's for interacting with non-CL software, you want a native-namestring, not a namestring (on platforms that have such a concept). Returning a namestring in this context I consider to be an attractive nuisance: people will use it because it's handy, but it will do the wrong thing. I believe that's the reason I didn't use the -pathname suffix: because it's the only sensible interface that's not overly complicated and not an attractive nuisance. Note that inferior-shell (a layer on top of run-program) knows to interpolate a CL pathname into a native-namestring, among other things. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org [I]f we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. — E. W. Dijkstra