RFC: f(::Function) variants for mktemp and mktempdir

[ghost]

While making some test code requiring temporary directories I remembered that Python has some awesome temporary file objects that you can combine with with-statements to make the clean-up automagical. With this PR, we can be just as awesome with our do-blocks:

mktempdir() do d
    touch(joinpath(d, "foo.md"))
end

mktemp() do p, io
    print(io, "鴨かも？") # Silly Japanese play on words.
end

"Bonus commits":

1. Re-enabling several tests in test/file.jl, that were disabled back in 02a6aab. For Windows compatibility? Now that Windows support the operations we should be able to re-enable them safely.
2. Moving several Unix-only tmp functions in file.jl into a single block protected by a @unix_only to follow the same pattern that was used for the corresponding Windows-only code.

[ghost]

Travis appears to have some sort of issue, I will try to force-push and see if it will make it pick up the PR.

[ghost]

Success for Linux, failed (timed out?) on OSX. Seems unrelated.

[ghost]

Travis passing, seems to have been a temporary hiccup.

[ghost]

There seems to be considerably less excitement about this than I expected. Am I really the only one that has had to deal with wrapping a ton of badly behaving third-party tools over the years? These use-cases, along with testing code is really where this kind of functionality shines. I really feel that small improvements like this showcases the awesomeness our language and makes our API appealing and keeps it on-par with "lesser" modern languages.

[jakebolewski]

You can remove the consts, they don't do anything inside of a function.

[jakebolewski]

I agree, this would be nice to have.

[tkelman]

I like the idea quite a bit, just haven't gotten a chance to test the PR.

[jakebolewski]

Not to sidetrack this discussion, but I'm wondering about the security concerns raised in the python docs for tempory files https://docs.python.org/3.4/library/tempfile.html#tempfile.mkstemp. Do we address any of them wrt tmp file creation?

[ghost]

@jakebolewski: Thank you for the comment about const, I have force-pushed an updated version.

Also, sorry to the community for calling out the lack of activity. I do realise that your time is valuable and limited. I am still a bit anxious as a contributor I guess, not trusting my own intuition.

[jakebolewski]

Needs a squash, but LGTM.

[ghost]

@jakebolewski: You mean squash the three distinct commits into a single commit? Wouldn't that make tracking changes and reverts considerably more difficult? Sorry to ask, but I don't think there is an authoritative statement in CONTRIBUTING.md.

[ghost]

Just to add very quickly so that I get this right in the future, if there was to be a squash, then the code move and re-enabling the tests should have been submitted as separate PRs? Sorry for adding them as "bonuses" in that case, I thought that they were just too minor to warrant their own PRs.

[nalimilan]

Nice addition. Could you add documentation for the new variants?

[nalimilan]

@jakebolewski Regarding security concerns, this looks OK to me on Unix as the code calls mkdtemp (I don't know on Windows though).

[staticfloat]

@ninjin I think you're okay with the three separate commits; you've got a good separation of concerns with these commits. Your other two commits are indeed minor, which is often a good indicator for a squash candidate, but really it's often a matter of taste. Don't worry about making PRs that are too minor, it makes it very easy to hit the "merge" button. :P

We already satisfy all of the python concerns that I can see: No race conditions, readable and writable only by owner, not executable, etc...

[ghost]

@nalimilan: I'll push the documentation on my stack.

We already satisfy all of the python concerns that I can see: No race conditions, readable and writable only by owner, not executable, etc...

@staticfloat: I love this, it is exactly the mindset one should have with an API.

[tkelman]

fails on windows at line 274, ispath(path) is true

[ghost]

fails on windows at line 274, ispath(path) is true

That is really odd and probably deserves an issue on its own. What this would mean is that tempname() on Windows actually creates a file, unlike its *NIX counterpart.

path = tempname()
@test ispath(path) == false

If someone with a Windows box and some Windows systems programming knowledge could have a look at the relevant code, it would be greatly appreciated.

[tkelman]

See http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991(v=vs.85).aspx

If a unique file name is generated, an empty file is created and the handle to it is released

[ghost]

@tkelman: Thanks a bundle, I will file a PR to disable the offending test for now and open a separate issue to discuss what to do about this discrepancy.

[nalimilan]

tempname is racy anyways, wouldn't it be safer to deprecate it? (Though of course a fix is needed until it's removed.)