Improve names of generated executables for scripts

[bacchanalia]

The motivation for this PR is that previously all executables generated for scripts were named "script". This was confusing from a process management standpoint.

Ideally the name of the generated executable would be identical to the name of the script, but currently the executable name is generated from the executable section in the generated .cabal file, and there is a limited character set that is legal for that name. Since there's no easy way to use the script name directly, I replace the illegal characters with '_'. Also on @jneira's suggestion, I prefix the name with "cabal-script-" to make clear to end users that it is a generated name.

It might be possible to detect it's a script on the the Cabal side and set things there appropriately to avoid the name mangling, but I don't think the added complexity is worth it.

This change already effects existing tests for scripts, and therefore does not need a standalone test.
I do not believe the change effects any exiting documentation.

[bacchanalia]

It looks like tests are failing on Windows to the file path length limit, which is by default 260, but some build products have path length 262.

[Mikolaj]

That's a bummer. I wonder if this can be remedied. Could you shorten the paths in your test for now?

[bacchanalia]

@Mikolaj yeah, I can shave 21 chars off pretty easily

[jneira]

Also on @jneira's suggestion, I prefix the name with "cabal-script-" to make clear to end users that it is a generated name.

We talked that it could help to reach that limit, but windows users are used to use short paths with haskell nevertheless.
But it exploded in tests 🤦

Maybe it is time to cut off the hash from the script binary full path (if you are not already doing it)?

[Mikolaj]

The prefix sounds useful. I think @bacchanalia is cutting corners only in tests, not in the actual code. Otherwise, we'd need to sit and google and ponder how to fix this properly.

[bacchanalia]

I'm getting the same error now, despite shortening the path to well under 260, so it seems the problem is something else.

edit: Could still be "D:\a\cabal\cabal\cabal-testsuite\PackageTests\NewBuild\CmdRun\ScriptNoExtention\cabal.dist\work\.\dist\build\x86_64-windows\ghc-8.6.5\fake-package-0\x\cabal-script-with_space\build\cabal-script-with_space\cabal-script-with_space-tmp\Main.o" if it's actually passed with the double back slashes.

[bacchanalia]

It is now confirmed to have been path length, since last patch fixed it.

[bacchanalia]

@jneira The hash doesn't even appear in the path that was too long.

[fendor]

This is a rather disgusting hack, we should have a better definition of cabal-syntax, but that's well out of scope here. Looks like a clear improvement to me, thank you!

[jneira]

lgtm, thanks for this nice refinement to your main patch

[bacchanalia]

@fendor I assume you mean the censor function? I agree but I couldn't find a clear definition of the legal character set anywhere, so that's what I came up with.

[bacchanalia]

Before I hit "merge_me" do you think this is could cause trouble for other people working on cabal on Windows, because they're base dir is any higher up they're going to get a test failure when they try to running tests? It might be better to wait for #4978 for that reason.

[fendor]

I couldn't find a clear definition of the legal character set anywhere

Neither can I, but there definitely is somewhere. And if not, there should be!

[bacchanalia]

@fendor Looking again I found the definition in "templates/Lexer.x", so I'm going to rewrite censor to use the definition of namecore transcribed from there.

[fendor]

Much better!