Cabal commands do not work with whitespace in path

[hua-en]

Describe the bug
Cabal commands do not work with provided paths when the paths contain white spaces. For example, if the path /home/USERNAME/Cabal Projects/app/Main.hs is provided instead of the path ./app/Main.hs or the path /home/USERNAME/cabal-projects/app/Main.hs, the command does not work. This is an issue for projects with parent directories containing white spaces.

To Reproduce
Steps to reproduce the behavior:

1. Create a new directory Cabal Projects in the home directory /home/USERNAME.
2. Run cabal init in the Cabal Projects directory.
3. Run cabal v2-repl ./app/Main.hs. The file should run correctly.
4. Attempt to run cabal v2-repl /home/USERNAME/Cabal\ Projects/app/Main.hs or cabal v2-repl "/home/USERNAME/Cabal Projects/app/Main.hs". The command fails with the error message "cabal: Unrecognised target syntax for '/home/USERNAME/Cabal Project/app/Main.hs'." for Cabal 3.6.2.0, and "Error: cabal: Failed extracting script block: {- cabal: start marker not found" for Cabal 3.10.1.0.
5. Create a new directory cabal-projects in the home directory /home/USERNAME.
6. Run cabal init in the cabal-projects directory.
7. Run cabal v2-repl ./app/Main.hs. The file should run correctly.
8. Run cabal v2-repl /home/USERNAME/cabal-projects/app/Main.hs. The file should also run correctly.

Expected behavior
The cabal command should run correctly in both the instance where the directory has no whitespace and the instance where the directory has whitespace in its name.

System information

• Linux, Fedora 37
• Tested with cabal versions 3.6.2.0 and 3.10.1.0
• Tested with ghc versions 9.2.5 and 9.4.4

Additional context
This problem causes issues with Haskell Language Server as HLS runs cabal commands from the root directory with the format cabal v2-repl "/home/USERNAME/Cabal Projects/app/Main.hs" in order to work, which causes issues when the intermediate directories have whitespaces.

[ffaf1]

I suspect 46987a9

cabal/cabal-install/src/Distribution/Client/ScriptUtils.hs

Lines 182 to 186 in d53b4d4

	(tc', ctx', sels) <- case targetStrings of
	-- Only script targets may contain spaces and or end with ':'.
	-- Trying to readTargetSelectors such a target leads to a parse error.
	[target] | any (\c -> isSpace c) target || ":" `isSuffixOf` target -> do
	scriptOrError target [TargetSelectorNoScript $ TargetString1 target]

Does this ring a bell, @bacchanalia?

[ulysses4ever]

@ffaf1 good bug hunting, thank you!

I'm curious though: 46987a9 concerns scripts but the bug report seem to point to a fresh cabal inited package. There may be something else at play? Or all cabal run go thorugh this part of code? How about cabal repl (which is also mentioned in the bug report)?

[bacchanalia]

The fact that this was failing on 3.6.2.0 suggests that I was right in the comment that readTargetSelectors would fail to parse targets that contain spaces was correct 😅.

I'm not sure I realized you could point to specific files as cabal targets, or I probably would have thought to fix this while working on the script stuff.

[bacchanalia]

@ulysses4ever It does look like I replaced an existing bug with another related bug though, so that will have to be fixed along with the original bug. I think I might actually have some time this week to look into it.

[bacchanalia]

While we're here, I assume we also want to support paths that contain ':' (which is also currently not supported)?

[ffaf1]

I would say “any path valid on the user’s system” would be perfect.

[bacchanalia]

I think whitespace and ':' are the only chars currently prohibited.

[mouse07410]

While we're here, I assume we also want to support paths that contain ':' (which is also currently not supported)?

I'd say - heck, yes!!

[ulysses4ever]

Colon has special meaning in target syntax: it separates the parts of a target. See https://cabal.readthedocs.io/en/stable/cabal-commands.html#target-forms

Space is also special in that it separates multiple targets.

Now, we’re used to the shell UX when enclosing a string into quotes allows special symbols. But that’s never been promised for targets. Trying to implement it is, perhaps, a noble goal (especially if there are legit use cases e.g. arising from how HLS calls cabal), but I’m slightly worried that it may be not trivial in fully backwards compatible manner.

[mouse07410]

"Noble goal" here is more important than "backward compatibility", IMHO.
Especially since "backward" way of dealing with colon-separated paths is nothing to be happy about.

[bacchanalia]

Space only separates targets in that it's passed as multiple arguments. Inside a single argument it's just disallowed (except for scripts, currently), so allowing spaces I don't think will cause problems.

Allowing ':'s is trickier because it can lead to ambiguity. A compromise might be to require paths with ':'s to start with '.' or '/'.

[ulysses4ever]

compromise might be to require paths with ':'s to start with '.' or '/'.

I don't like when a tool is trying to be smart. But maybe it's just me.

Also, keep in mind that colon is simply forbidden as a part of a path on all Unix systems (I think). That was probably the original motivation for picking it in the target syntax.