don't normalize paths in expand_path

[Witcher01]

Remove normalizing paths in "expand_path" and expand environment variables. Paths don't need to be normalized, but doing this on non-path parameters (i.e. URLs) might cause bugs.

Reported-by: s-hamann
Closes: #1021

[WhyNotHugo]

I'd have to recall why we normalised paths in the first place. The initial commit isn't very helpful: da8bba8 But I have a vague impression that it makes a difference in some situations (e.g.: when a user-provided path is compared with an internally-generated path maybe?).

But yeah, we shouldn't normalise paths on URLs, that's outright wrong.

[Shadow53]

Looks like the readthedocs job is preventing this PR from being merged? It's saying the .readthedocs.yaml file can't be found in the repository, which I don't see on main either.

Would like to see this merged as I am also running into this issue.

[WhyNotHugo]

I reviewed this and #1021 a bit further.

If a password has $HOME, we'd still be messing it up. I think that we need to stop calling expand_path on some types of fields.

[WhyNotHugo]

Exactly which scenario does this patch fix?

[Shadow53]

Exactly which scenario does this patch fix?

For me, it's the path normalization issue. I use 1Password, and the cli command to get a password is op read op://<vault>/<item>/password. The URI bit gets normalized to op:/<vault>/..., which causes the command to fail.

I can use a script to hide the real command so this doesn't happen, but I'd rather that not be a long-term solution.

[Shadow53]

If a password has $HOME, we'd still be messing it up. I think that we need to stop calling expand_path on some types of fields.

Since both command and shell are supported, one possible option is to let the shell expand environment variables and have command pass all arguments verbatim.