On 8/22/16 Aug 22 -5:16 PM, Faré wrote:
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).
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)
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.
Best, r