Tab auto-completion in PowerShell fails with EOFError: Escaped new line

[drx777]

see previously closed ticket #240

I can still reproduce this issue with Windows 11 PowerShell:

$ shell> pselect --path t<TAB>arget/<TAB>
org. jline.reader.EOFError: Escaped new line
at org.springframework.shell.Jline.ExtendedDefaultParser.parse(ExtendedDefaultParser.java:138) ~[spring-shell-core-3.4.0.jar!/:3.4.0J
at org-jline.reader.impl.LineReaderImpl.doComplete(LineReaderImpl.java:4459) ~[jline-reader-3.26.3. jar!/:na]
at org-jline.reader.impl.LineReaderImpl.doComplete(LineReaderImpl.java:4435) ~[jline-reader-3.26.3.jar!/:na]
at org.jline.reader.impl.LineReaderImpl.expand0rComplete(LineReaderImpl.java:4374) ~[jline-reader-3.26.3.jar!/:na]

Here's the relevant code:

@ShellComponent
public class ComponentCommands extends AbstractShellComponent {

  @ShellMethod (key = "pselect", value = "Path input", group = "Components")
    public String pathSelector (@ShellOption(valueProvider = FileValueProvider.class, help = "path to input file", value = "path") String path) {
      Path filePath = Path.of(path);
      return (Files.exists(filePath) ? "file exists" : "file not found") + filePath.toAbsolutePath();
    }
  }
}

However, using double backslash (\\) does work as expected, i.e. the path lookup works - once. Tab completion does then de-duplicate the backslash though and in doing so duplicates the initial character(s), so it's still not feasible, but that seems to be a distinct issue.

pselect_e2.mp4

I started to write a specific FileValueProvider for windows using double backslashes, but that had the same issue with the first character(s) replacement rendering the input invalid.

[DavJaveiro]

Hi, I’m interested in investigating this issue.

I noticed that it is still open and currently has no assignee. I also
could not find an existing pull request addressing it.

Before starting, I would like to confirm whether this behavior is still
considered a valid issue on the current main branch and whether a
contribution would be welcome.

My initial plan would be to:

1. reproduce the behavior on Windows using the current main branch;
2. identify whether it originates in ExtendedDefaultParser, the file
   value provider, or the JLine integration;
3. add a focused regression test before proposing a minimal fix.

Would this be an appropriate direction?