Add template to mktemp commands, for compatibility with earlier versions of MacOS.

Ref: https://forum.toplap.org/t/trouble-setting-up-tidal-stack-install/902/20

Did you check whether this is portable across all platforms? mktemp (1) is not specified by posix: https://stackoverflow.com/questions/2792675/how-portable-is-mktemp1

No, but I can say that it worked for that MacOS 10.9 user, and it works for me under Linux mint. I got the fix from the yarn installer: https://github.com/yarnpkg/yarn/issues/1984 So it seems that specifying the template is generally supported, and in the case of earlier MacOS versions, required.

Well, it has to work for all platforms ;)

Afais the FreeBSD Version does something different on -t.

I thought ghcup only supported MacOS and Linux?

Nope: https://gitlab.haskell.org/haskell/ghcup/blob/master/.download-urls#L74

Also, ghcup tries to be POSIX compatible, as described in the readme. Whenever we can't achieve it, because POSIX is underspecified, we try to be as portable as possible.

The -t parameter seems to do the same thing under FreeBSD https://www.freebsd.org/cgi/man.cgi?query=mktemp&sektion=1 Otherwise, the parameter could be added if Darwin is detected

Yes, I think we need to write a function that wraps mktemp and only executes the explicit template form if OSX is discovered.

This FreeBSD version also seems to require -t: https://www.freebsd.org/cgi/man.cgi?query=mktemp

The portability link you posted suggested Darwin's version is based on FreeBSD

It might in the end be safest to specify it for everything, if we can verify it works under the supported platforms.

I mean, from the manpage, the FreeBSD version seems to either require a template to be set as a 'bare' parameter, or via a prefix set with -t, from with the template is constructed along with an environment variable. I don't have access to FreeBSD to verify this, though.

The linux manpage says this of -t:

       -t     interpret  TEMPLATE as a single file name component, relative to
              a directory: $TMPDIR, if set; else the directory  specified  via
              -p; else /tmp [deprecated]

That deprecated notice worries me, but I don't know whether the parameter is deprecated, or the defaulting to /tmp.. That is, I don't know whether the -t is going away, or is becoming mandatory!

Sorry for the multiple posts. After more manpage reading my conclusion is that:

• Some *BSD derived platforms , including MacOS 10.9 require a template to be set
• The -t parameter seems to be a cross-platform way to get the temp file / directory to be created under $TMPDIR or /tmp, which we probably want

So FWIW my vote is to merge this as-is, but if there's someone who can test it under FreeBSD that would be better.

I've booted a FreeBSD 12 VM

mktemp -d -t ghcup.XXXXXXXX works, but creates a folder like /tmp/ghcup.XXXXXXXX.u2Uq32ue. A little bit messy.

mktemp -d works too, creates a folder like /tmp/tmp.v9ACTpFVjm, seems to have the same behaviour as linux

Is it worth complicating the code to avoid a messily named temporary folder?

Is it worth complicating the code to avoid a messily named temporary folder?

My initial suggestion still stands. No one ever reported problems with mktemp -d, so let's keep that for ALL platforms where it works and only change it on the platforms where it doesn't.

Any progress?

added 1 commit

• 264d84be - provide temporary directory name prefix only for Darwin

Compare with previous version

I've had my best go at this. I haven't got direct access to a mac to test it, though. However, I have verified that mktemp -d -t ghcup does as intended on at least one mac.

Now that I think about it, check not just if the variable is set, but also if the directory exists!

https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html

Also, we are basically creating a global variable and don't know when a caller reads it. So the caller has to unset it as well. This is problematic API.

I suggest to remove the error checks and just have a simple if else for the mktemp call, without setting any variable and without erroring out. Then the caller Has full control.

Ah, I've barely done any shell programming before so don't know these idioms. But I didn't think I was making an api, just a function for use within the same script. As far as I can tell, this has the same behaviour as the previous version, in terms of tests and variables.

It would be good to have this resolved soon, I just ran a workshop and two people couldn't install ghcup due to this issue.

mentioned in issue #121 (closed)

I'm taking a look now

mentioned in merge request !126 (merged)

Since I don't like the implicit setting of tmp_dir in mktempdir I made an alternative version: !126 (merged)

merged

Thanks, that does look better

Hi, The current mktempdir function is not working on my OSX 10.10 Yosemite machine. I believe the .XXXX suffix is necessary on this platform. Not a very smart fix, but ghcup could just try the same mktemp command with the suffix if it fails without?

Ok, I found the culprit. Sorry to criticise, but this is a stupid mistake: the test against mydistro = "darwin" in mktempdir was always failing since mydistro was not set in that function. Great.

I'll create a merge request ASAP. Don't make these kinds of mistakes please.

Here's the merge request. I've never been able to get ghcup to run on my machine, and this seems to have been the reason all along.

!130 (merged)

mentioned in merge request !130 (merged)

mentioned in issue #130 (closed)