Repository navigation
New-Item -ItemType SymbolicLink should support creating symlinks with relative paths #3500
Description
Being able to create symlinks using relative paths is an important feature that both the ln utility on Unix and cmd's built-in command mklink on Windows support.
Currently, PowerShell invariably resolves the specified path to an absolute path when a symlink is created.
(#801 brought us the ability to create symlinks to non-existing targets, but even they are invariably resolved to an absolute path when the symlink is created).
Instead, the symlink should be defined with the target path exactly as specified.
Steps to reproduce (Unix)
$null = New-Item -ItemType SymbolicLink /tmp/$PID -Target ./foo -Force
readlink /tmp/$PIDExpected behavior
./foo
The symlink should be defined with the target path exactly as specified.
Actual behavior
/Users/jdoe/foo
The symlink was unexpectedly defined with an absolute path.
Environment data
PowerShell Core v6.0.0-alpha (v6.0.0-alpha.17) on Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64Reacted by tophf, jansohn, nwsparks, Steve Baker, ForgottenUmbrella, Mikhail Kviatkovskii, Kagami Sascha Rosylight, elca-lan and Felix Becker
Activity
elca-lan commentedon Jan 25, 2019
Some official comment would be helpful here. I just ran into this issue and I must say, in most scenarios that I have so far encountered (e.g. symlinks in git repositories) absolute symlinks are not exactly very helpful.
On Windows, I can still work around the issue by calling out to
cmd /C mklink /D mylink .\mytargetbut this really seems like a fairly fundamental flaw in the cmdlet.mklement0 commentedon Jan 25, 2019
Agreed, elca-lan. Steve Lee (@SteveL-MSFT), perhaps this can be marked as up-for-grabs?
On Unix-like platforms the workaround is to use
ln -s ./mytarget mylink.attempting to add symlink (shortcut) to windows build