nix-repl> builtins.readFile /path/with/at@char/in/it
error: syntax error, unexpected '@', expecting end of file
at «string»:1:32:
1| builtins.readFile /path/with/at@char/in/it
| ^
Where is the proper place to report bugs with the Nix language itself? I am looking at Nix/Nixpkgs/NixOS · GitHub where there are areas for the package manager, docs, etc. Is there some name for the language nix uses, and a separate project for that? Or shall I just file under NixOS/nix (i.e. the package manager also has the language parser + standard libraries).
First of all, the homeDirectory setting for home-manager should not be a path literal syntax like /home/foo. It should be a string like "/home/foo" Apparently it applies toString so that actually shouldn’t matter. But, in case you do need an @ symbol in a path value, you can append strings to paths, like ./foo + "@bar", which returns the path value for ./foo@bar, even if you’re not allowed to represent that with path literal syntax like ./foo@bar.
Indeed the discussion there has lead to a simple fix that I have verified on my system. Either way, best close this thread and let the experienced people sort things out on the issue thread.
It is not reasonable for Nix’s syntax to support all valid file system paths. For instance, file system paths permit spaces in file names. It’s not reasonable for Nix to support that in path literal syntax, because spaces are semantically relevant in Nix syntax (function application). I’m sure there’s countless other examples, since file system paths are basically allowed to include any bytes except for / (and I think \0?). As I said before, the solution is to use concatenation with a string literal. ./. + "@foo" → ./@foo, ./foo + " bar" → ./foo bar
Except that you can escape those things. There is no excuse for not being able to handle a file path with characters like “@”, it needs to just work. I use “@” to group my projects by organization if one exists and Nix explodes if I use it in any of those repositories in a way that references the path. That isn’t normal.
That’s a bug in something, but not Nix. User-provided data—including paths—shouldn’t be sent to Nix via --arg, because --arg doesn’t escape stuff. It should come via --argstr instead, and if it needs to be consumed as a path instead of as a string, converted by the consumer via path concatenation just as @ElvishJerricco has said.