Move realpath() earlier in cmdlineargs test

[staticfloat]

This should hopefully fix issues such as #34418 (comment)

[stevengj]

If this is needed on Windows, shouldn’t it be part of the mktempdir implementation?

[staticfloat]

I think probably yes.

[stevengj]

I'm still confused about the real source of the bug here. Why do we need the realpath result?

Currently, mktempdir(), mktemp(), and tempname() all use tempdir() as their default parent directory. The tempdir() function gets its path from a user environment variable (TMP etc.), and hence it may be a path that does not yet exist or a path spelled with the "wrong" case (on Windows or Mac).

I just checked, and none of mktempdir(), mktemp(), or tempname() currently return the realpath result on Windows — all of them preserve the case that was passed (and on my system return the "short" 8.3 path since tempdir() is a short path). Similarly, on MacOS (also case-insensitive, case-preserving), if I set ENV["TMPDIR"]=uppercase(tempdir()) then all of these functions currently return the uppercase path.

I see three options:

1. Continue to do what we do now — preserve the user environment's specified path as-is in all returned paths. Any caller that needs the realpath (such as these tests, apparently) should call this manually.

2. Change tempdir() to return the realpath() if the path exists. This seems potentially dangerous, however — if they current path is a symbolic link, but the symbolic link is changed to a different target after the tempdir() call

3. Keep tempdir() as-is, but change mktemp etcetera to return the realpath, which should be safer once the file is created. (If someone renames the file or rearranges symbolic links after the mktemp call, we already have potential problems when you try to delete the file.)

[KristofferC]

Bump, all Windows CI currently fails so it would be good to do something here.

[stevengj]

I think it's fine to merge this for now and debate whether we want to call realpath by default for mktemp etc. later.

[vtjnash]

These tests are probably demonstrating bad practice and should be using samefile instead of ==, but they're only tests.

[staticfloat]

I think Jameson is correct; I think the reason the realpath() is needed has more to do with the tests trying to ensure that two things are the same file than that mktempdir() is doing something fundamentally wrong. That being said, it does seem reasonable to me that if a standard library function returns you a pathname to a file, it would be the most "canonical" way to refer to that file, which realpath() seems to be to me.