From c63195f880d7664edaa0de45ef5b374f00daa33c Mon Sep 17 00:00:00 2001 From: Sean Estabrooks Date: Sat, 21 Sep 2024 13:51:20 -0400 Subject: [PATCH] Handle # and ? characters in directory path When referencing the current-working-directory, before it is set by an OSC 7 escape sequence, we ask the OS for the correct path. This path was then being parsed as a URL; where a "#" or "?" character would be interpreted as the start of a fragment or query component of a URL -- which is a mistake. So this change parses the returned directory as such, where those characters will be treated as a normal character in the path. Nothing is changed for the OSC 7 escape sequence case. In that case, the application must percent-encode the path before sending, so that those characters are not misinterpreted. As per issue #6158 reported by Syntaxheld --- mux/src/localpane.rs | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/mux/src/localpane.rs b/mux/src/localpane.rs index 09f728780..cc817178f 100644 --- a/mux/src/localpane.rs +++ b/mux/src/localpane.rs @@ -1045,17 +1045,14 @@ impl LocalPane { { let leader = self.get_leader(policy); if let Some(path) = &leader.current_working_dir { - return Url::parse(&format!("file://localhost{}", path.display())).ok(); + return Url::from_directory_path(path).ok(); } return None; } #[cfg(windows)] if let Some(fg) = self.divine_foreground_process(policy) { - // Since windows paths typically start with something like C:\, - // we cannot simply stick `localhost` on the front; we have to - // omit the hostname otherwise the url parser is unhappy. - return Url::parse(&format!("file://{}", fg.cwd.display())).ok(); + return Url::from_directory_path(fg.cwd).ok(); } #[allow(unreachable_code)]