When the user specified target path is like ./dir or .\dir, the value returned from Path.Combine would be like <sym-dir-path>{directory-separator}./dir or <sym-dir-path>{directory-separator}.\dir. This may not be a problem on Windows (which I'm not certain), but on Unix platform, a path like /home/user-a/.\temp cannot be resolved to /home/user-a/temp.

So, I think we should still remove the .\ or ./ prefix for a relative path.

Also, do we want to normalize directory separators used in the -Target? I mean, if user specifies .\subdir\dir on Linux, shall we normalize that to be ./subdir/dir?

Also, do we want to normalize directory separators used in the -Target? I mean, if user specifies .\subdir\dir on Linux, shall we normalize that to be ./subdir/dir?

There are already issues with path normalization on Unix since \ is valid char there. I think we shouldn't add one more.

Thanks for the review, these are both good observations.

Just writing down my thoughts for the implementation:

• The path to the symlink is passed already resolved and pre-processed, but the -Target/-Value is passed as-is, since the previous layers don't know how it's used.
• PowerShell supports both \ and / as directory separators on all platforms. Therefore, we should convert separators for the value that we store in the symlink target to match what rest of the shell does. This will prevent the user from symlinking to paths that contain \ on Linux/Mac, but imo that ship has sailed when PowerShell Core went with emulating \ and consistency with the rest of PowerShell is now more important than allowing the user to create symlinks to files that they cannot create through PowerShell anyway.
• Personally, I wouldn't do any other processing on -Target. Don't see any reason to remove .//.\, since they should work fine as long as the separators are correct.
• Since the file/directory distinction for symlinks is not a thing on Linux/Mac, we could just remove the whole logic around looking up the target and only use it on Windows. However, we return either FileInfo or DirectoryInfo from the command, so we need to know the type of the target anyway.
• While looking at the implementation, I noticed that when creating a hardlink, we make -Target relative to the current working directory. With the change implemented in this PR, this will be inconsistent with symlinks. Is that a problem? Shouldn't we also change hardlink creation to be consistent?

What needs to be implemented:

• unify slashes in -Target to the correct platform-specific separator before resolving the target

@daxian-dbw Do you agree?

• Personally, I wouldn't do any other processing on -Target. Don't see any reason to remove .//.\, since they should work fine as long as the separators are correct.

That's actually always annoyed the hell out of me to the point I manually remove them. I use ln.exe, which exposes the target via GUI.

I'd really appreciate if those were removed.

@God-damnit-all In that case, just don't pass paths with ./ as -Target. Other people may have the opposite preference, and since both options behave identically in practice, I don't see any reason to force one or the other.