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.

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 onmain either.

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

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 callingexpand_path on some types of fields.

Exactly which scenario does this patch fix?

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 isop read op://<vault>/<item>/password. The URI bit gets normalized toop:/<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.

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

Since bothcommand andshell are supported, one possible option is to let the shell expand environment variables and havecommand pass all arguments verbatim.