Scoop: Can't use scoop apps as a replacement for system apps because of app path

[Murazaki]

Your paths are version dependent, which means every update of the app will break the pathnames.

Solution : have symlinks pointing to latest versions.

[deevus]

Only for a subset of apps such as nodejs that are used themselves to install packages. Most apps have their binaries shimmed into the scoop/shims directory, which does not change between versions as long as the binary names stay the same in their scoop manifest.

Shims are like symbolic links, but do not require administrator privileges to create. If you're using absolute paths to an app in your work, use the shimmed file, not the path to the app version directory.

[nightroman]

@deevus, shims are good but they may not work well in all possible scenarios.

• Sometimes I want to avoid shims (for various reasons, including name conflicts).
• Some tools and settings depend on their actual install directory, not shims directory. My two pain points, for example:
  
  
  
  • I install 7zip, then use its file manager 7zFM.exe (shim or not does not matter). It offers me to associate archive file extensions with it. When this is done its actual path is stored in the registry with these associations, not the starting shim path. Thus, after upgrading all associations are broken.
  
  
  • I install Sysinternals Suite, then use procexp.exe (shim or not does not matter). It offers me to replace the native process explorer with it, so that it starts on Ctrl+Shift+Esc. This also stores its actual exe path in the registry, not the starting shim. Thus, after upgrading Ctrl+Shift+Esc is not working as I want.
  
  

In other words, I would be interested in some options to deal with such pain points.

[Murazaki]

I ran into the issue trying to use bash from Git mingw folder (ConEmu users use this bash version for Git Bash and Docker).
Then I wanted to unzip the Git version from cache and ran into @nightroman 7zip issue 😅

[lukesampson]

@nightroman Do you know if using symbolic links to 7zFM.exe or procexp.exe stores the path of the symlink instead of the actual program? If symlinks work, we could look at optionally using those instead of shims (with a config setting) given that Windows seems to be moving towards better symlink support.

[nightroman]

I played a little bit with symbolic links to files instead of shims. I think
this may work for some standalone tools (procexp). But it does not work for
others (7zFM) that expect their satellite files in the same locations (DLLs,
resources, etc). Both procexp and 7zFM started fine from links but 7zFM failed
to open an archive later.

Another way with directory junctions looks more promising to me.
I created a directory scoop\links and there created two junctions

• 7zip pointing to C:\Users\rkuzmin\AppData\Local\scoop\apps\7zip16.04 (note fixed version name, standard scoop approach)
• SysinternalsSuite pointing to C:\Users\rkuzmin\AppData\Local\scoop\apps\SysinternalsSuite\current (note current, my trick)

Then I started both from junctions and did the following:

• associated 7zip with archives
• told to use procexp as task manager

Then I investigated the stored settings:

7zip

command ftype 7-zip.7z shows

7-zip.7z="C:\Users\rkuzmin\AppData\Local\scoop\links\7zip\7zFM.exe" "%1"

It looks like success, the junction path is stored.

procexp

The key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe

has value Debugger

"C:\USERS\RKUZMIN\APPDATA\LOCAL\SCOOP\LINKS\SYSINTERNALSSUITE\PROCEXP.EXE"

It looks like success, too, the junction path is stored.

Then I tried to rename scoop\apps\7zip16.04 (junction got broken) and
recreate the junction with the old name pointing to the new folder.
Archive associations worked just fine after this.

Thus, I would propose to think of a configurable option like this.
For example, as I did, we have a directory scoop\links and create there
junctions pointing to the latest installed (as usual) directories of apps.

Related options like adding to path or environment variables in this case should
point to the junction, indeed. And a user is supposed to start the apps from
justions, as if they are installed there.

[deevus]

Great work! Can we create junctions without elevated prompt?

On Sat, Dec 31, 2016 at 5:57 PM Roman Kuzmin [e-mail]
wrote:

I played a little bit with symbolic links to files instead of shims. I
think
this may work for some standalone tools (procexp). But it does not work for
others (7zFM) that expect their satellite files in the same locations
(DLLs,
resources, etc). Both procexp and 7zFM started fine from links but 7zFM
failed
to open an archive later.

Another way with directory junctions looks more promising to me.
I created a directory scoop\links and there created two junctions

• 7zip pointing to
  C:\Users\rkuzmin\AppData\Local\scoop\apps\7zip16.04 (note fixed version
  name, standard scoop approach)
• SysinternalsSuite pointing to
  C:\Users\rkuzmin\AppData\Local\scoop\apps\SysinternalsSuite\current (note
  current, my trick)

Then I started both from junctions and did the following:

• associated 7zip with archives
• told to use procexp as task manager

Then I investigated the stored settings:

7zip

command ftype 7-zip.7z shows

7-zip.7z="C:\Users\rkuzmin\AppData\Local\scoop\links\7zip\7zFM.exe" "%1"

It looks like success, the junction path is stored.

procexp

The key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NTCurrentVersion\Image File Execution Options\taskmgr.exe

has value Debugger

"C:\USERS\RKUZMIN\APPDATA\LOCAL\SCOOP\LINKS\SYSINTERNALSSUITE\PROCEXP.EXE"

It looks like success, too, the junction path is stored.

Then I tried to rename scoop\apps\7zip16.04 (junction got broken) and
recreate the junction with the old name pointing to the new folder.
Archive associations worked just fine after this.

Thus, I would propose to think of a configurable option like this.
For example, as I did, we have a directory scoop\links and create there
junctions pointing to the latest installed (as usual) directories of apps.

Related options like adding to path or environment variables in this case
should
point to the junction, indeed. And a user is supposed to start the apps
from
justions, as if they are installed there.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/lukesampson/scoop/issues/1179#issuecomment-269852968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0Qgiwmy2bRLxfljCQ7hQywHXKBL01Aks5rNfzQgaJpZM4LYM6o
.

[nightroman]

Some quick search tells me that mklink needs elevation. Perhaps this is an inevitable limitation. But the target audience mostly can run scoop elevated, I believe. And scoop may check this on certain operations and fail gracefully.

[lukesampson]

Thanks @nightroman. When I tested just now, it seems junctions can be created without admin privileges (using /j param for mklink). E.g.

mkdir orig                      # create the directory to be linked to
echo "testing" > orig/test.txt  # write a test file in original directory
cmd /c mklink /j junction orig  # create the junction (no powershell equivalent)
type junction/test.txt          # outputs contents of the file in original directory
cmd /c rmdir junction           # remove the junction, without affecting original directory (no powershell equivalent)
cmd /c rmdir orig               # clean up after this test

mklink without /j does seem to require admin elevation.

Also, I like the idea of having a ~scoop\apps\[app]\current directory (as in the SysinternalsSuite example). Seems cleaner to have it under the app directory.

[nightroman]

it seems junctions can be created without admin privileges (using /j param for mklink)

This is a good news.

I like the idea of having a ~scoop\apps[app]\current directory (as in the SysinternalsSuite example). Seems cleaner to have it under the app directory.

Yes, I also like this.

[lukesampson]

Okay, I'm going to try implementing this now.

[lukesampson]

I think it should work now, but it'd be great if anyone interested can try it out and provide feedback.

To enable junctions you need to first run:

scoop config USE_JUNCTIONS 1

If it doesn't work and you want to disable this, run scoop config rm USE_JUNCTIONS.

When a new version of an app is installed, the ~/scoop/apps/[appname]/current directory junction is created, pointing to the version that was installed, e.g. ~/scoop/apps/7zip/current will point to ~/scoop/apps/7zip/16.04.

All paths, shims and environment variables should point to the current directory, rather than the actual version directory.

You should see a message when the junctions are created and removed, e.g.

linking ~\scoop\apps\chromedriver\current => ~\scoop\apps\chromedriver\2.27

and

unlinking ~\scoop\apps\chromedriver\current

[nightroman]

It seems to be working fine. That was quick! It's a very nice new year present, thank you very much!
Happy New Year!!!

[lukesampson]

Great! Thanks for investigating and finding the solution. Happy New Year!

[deevus]

Works great :) 👍

[Murazaki]

Thanks for your very quick response ;) ! Happy New Year !

[lukesampson]

I've made this the default behavior, so there's no need to set USE_JUNCTIONS any more. I'll close this issue now. Thanks everyone.

[nightroman]

It would be useful to document this somehow. People not familiar with junctions may be confused. E.g. their apps directories will look twice as big as they are in fact.

[lukesampson]

Good point. I've added this page to the wiki. Please let me know if the tone is wrong. And please go ahead and make corrections if it's confusing or missing info.