Details
-
Type:
Bug
-
Status: Being tested
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: 2.11.4.0, 2.11.4.1
-
Fix Version/s: 2.11.4.2
-
Component/s: Command Line Interface
-
Labels:
-
Urgency:Urgent
Description
The jalview.ps1 launcher for Windows command line (this is what ultimately runs when you run 'jalview' from the command line) fails.
There is quite a lot of output but the only real failure is within the bespoke
Readlink-f function, written to work out a "realpath" for the Jalview/getdown appdir. Readlink-f is meant to work like the GNU "readlink -f" and return an absolute path that doesn't use any symbolic links. This is sort of needed in case a symbolic link is being used to point at the launcher script, or jalview's bin dir. Symbolic links do now exist on Windows filesystems.
Readlink-f iterates up each parent dir of the running script in order to trace any symbolic links that exist in any of those parents and replace them with the target path.
When running jalview from the command line on a UoD managed Windows desktop, the appdir is in the expected location of
C:\Users\bsoares\AppData\Local\Jalview
and ReadLink-f iterates up these dirs.
For an unknown reason, when it gets to C:\User\bsoares\AppData it says that
Get-Item: Could not find item C:\Users\bsoares\AppData.
(even though it would already have checked two dirs below that).
I imagine this might be down to some obscure network mapping setting in Windows.
Readlink-f is trying to solve a niche problem on Windows (less so on macOS/Linux/Unix) and a test has shown that Resolve-Path builtin will work, though it will fail in other circumstances as it doesn't resolve symbolic links to their target. In Windows this is much less likely to be a cause of a problem (it would be a problem if there is a symbolic link pointing to within the Jalview appdir, and the bin is put onto the user PATH so there is no need for this).
Note I am also trying to maintain this script to be compatible with both PowerShell 5.1 and later versions, since 5.1 is the pre-installed version in Windows 10. At some point this will become an unrealistic goal.
There is quite a lot of output but the only real failure is within the bespoke
Readlink-f function, written to work out a "realpath" for the Jalview/getdown appdir. Readlink-f is meant to work like the GNU "readlink -f" and return an absolute path that doesn't use any symbolic links. This is sort of needed in case a symbolic link is being used to point at the launcher script, or jalview's bin dir. Symbolic links do now exist on Windows filesystems.
Readlink-f iterates up each parent dir of the running script in order to trace any symbolic links that exist in any of those parents and replace them with the target path.
When running jalview from the command line on a UoD managed Windows desktop, the appdir is in the expected location of
C:\Users\bsoares\AppData\Local\Jalview
and ReadLink-f iterates up these dirs.
For an unknown reason, when it gets to C:\User\bsoares\AppData it says that
Get-Item: Could not find item C:\Users\bsoares\AppData.
(even though it would already have checked two dirs below that).
I imagine this might be down to some obscure network mapping setting in Windows.
Readlink-f is trying to solve a niche problem on Windows (less so on macOS/Linux/Unix) and a test has shown that Resolve-Path builtin will work, though it will fail in other circumstances as it doesn't resolve symbolic links to their target. In Windows this is much less likely to be a cause of a problem (it would be a problem if there is a symbolic link pointing to within the Jalview appdir, and the bin is put onto the user PATH so there is no need for this).
Note I am also trying to maintain this script to be compatible with both PowerShell 5.1 and later versions, since 5.1 is the pre-installed version in Windows 10. At some point this will become an unrealistic goal.