tilde_expand in client fails to resolve path

[tgauth]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

When passing, ~ as part of a path, i.e. -i ~\.ssh\example_key, the path should resolve to the user's home directory.

Expected behavior

For `user` it would resolve to - `C:\users\user\.ssh\example_user`

Actual behavior

For `user` the following error occurs - `tilde_expand: No such user \\.ssh\\example_key`

Error details

No response

Environment data

Version 8.9 and above

Version

9.8.1.0

Visuals

No response

[tgauth]

temporary workaround: pass path in with forward slashes, i.e. -i ~/.ssh/example_key

[mgkuhn]

Isn't the Windows equivalent of ~/ provided by %USERPROFILE%\?

If Windows users want tilde expansion, shouldn't this better be added to either a Windows shell, such as PowerShell or CMD.EXE, or perhaps to the command-line parser that comes with Microsoft's C runtime, which on Windows does some of the jobs (quote processing, word splitting) that on POSIX systems the shell does. This way, one will not have to add such a function to each individual command-line application, like ssh and many others, but can do it once for all Windows command-line applications.

[mgkuhn]

Longer-term suggestion to Windows Command Line project management, to solve the underlying problem of POSIX and Windows command-line processing currently being very different:

• ship a POSIX shell with Windows (which does all the usual argument expansions, including tilde expansion); this could start out as a Windows port of something like pdksh, dash or zsh.
• give that POSIX shell some new interface to application programs that use the Microsoft C run-time, to bypass the traditional CommandLineToArgv command-line parser there and deliver an already word-split argv[] array directly from such a shell to the application's main() function

The problem: Windows currently hands over a command-line as a single string, which the application then retrieves via GetCommandLine and splits via CommandLineToArgv. This seriously complicates command-line processing, as the task is currently split in a rather strange and highly complex way between the shell and the application's C run-time. Instead, just do it like Unix and standardize a way for a shell to hand over an Argv array of strings to an application, and lots of tricky quoting problems and corner cases will vanish.