Scoop fails to update pwsh

[fluffynuts]

Bug Report

I'm re-raising because ScoopInstaller/Scoop#4838 was just closed out. Trying to update pwsh again today, and I kept getting the error that it can't update because it's in use. It took me a while to realise that using cmd.exe was not enough to get this to work - I had to break out the venerable powershell.exe

That issue suggests a fix too - that if the expectation is that the user should use powershell.exe, then scoop could do so too.

Current Behavior

Cannot update pwsh.exe, even when no pwsh.exe is running, because the app is in use by scoop. Classic chicken-and-egg.

Expected Behavior

Scoop should update pwsh - either use powershell.exe to do the work, or some other method that doesn't rely on pwsh.exe

Possible Solution

• use powershell.exe to run the update for pwsh
• when using pwsh out of scoop, perhaps clone off the app instance to a temp folder and launch that pwsh.exe to do the upgrade. This could be part of the regular way-of-working for scoop, so it doesn't have to be a special case. Perhaps scoop could have a runtime folder with a copy of pwsh in it and the pwsh updater could spawn a post-process to update the runtime folder once update is complete, or scoop could schedule that work to be done like how other installers do on windows: at the next reboot.

System details

Windows version: 11
OS architecture: 64bit
PowerShell version: 7.2.3 (now)

Scoop Configuration

{
  "lastUpdate": "2022-04-29T08:43:43.9468502+02:00",
  "SCOOP_REPO": "https://github.com/ScoopInstaller/Scoop",
  "SCOOP_BRANCH": "master"
}

[rashil2000]

The solution proposed is too complicated and flaky. I would really not recommend that when the simple workaround is to just use PowerShell.exe whenever there's a pwsh update. I don't feel the added complexity is justified enough for a single application that too which receives updates every 3-4 months.

[fluffynuts]

there are lots of ways to solve this:

• stop distributing pwsh as scoop cannot effectively manage this app in the current manner
• do the update, but not link in the new pwsh - use the "update at reboot" mechanism that other installers use- don't use pwsh to run scoop scripts - if there's a known issue, and powershell.exe works, then use that. This update used to work, so there was a time that this wasn't an issue, but now there's a regression. This is literally the simplest fix, because, looking at the scoop shim:

#!/bin/sh
# C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1
if command -v pwsh.exe > /dev/null 2>&1; then
    pwsh.exe -noprofile -ex unrestricted -file "C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1"  $@
else
    powershell.exe -noprofile -ex unrestricted -file "C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1"  $@
fi

so scoop expects to work with the venerable powershell.exe ( > v5) and updates to this will be handled by the OS. I've just hacked scoop to do exactly this (use powershell.exe instead of pwsh.exe) and it works 100%

what benefit comes from using pwsh.exe and locking up the local install for pwsh?

[rashil2000]

Pwsh is the latest and greatest release of PowerShell, is faster, less buggy and continually updated, so it will be used if found. This behaviour will not be changed.

PowerShell 5.1 has been in maintenance mode for quite a few years now, and does not get updates (only critical security fixes) and Microsoft does not recommend using it if the newer Pwsh is compatible with the system.

[yonizaf]

Pwsh is the latest and greatest release of PowerShell

This makes zero sense to me. If pwsh7 is really this good and Microsoft recommends its use, why is Powershell 5 installed by default on both Windows 10 AND Windows 11, while Powershell 7 is not even in the "optional features" and needs to be installed externally?

One of the most important qualities of any software is predictability. PS5 is still included in Windows 11 exactly because it's stable and only receives security updates. Much like cmd.exe, it's here to stay, and scoop can only benefit for its own predictability by relaying on it when possible, over pwsh7 which still gets breaking changes from time to time.

Also:

I don't feel the added complexity is justified enough for a single application

This is very much an issue of predictability. You can't say "just for this app, do something different". How are people to know they need to do something different? this behavior is not properly documented, and this is not just any app, this is an app that scoop depends on, and that you named "the latest and greatest" and claimed that everyone should use, yet you send people to look for workarounds just so they could update it?...

[fluffynuts]

It's tough because I've tried winget (nothing installs due to some permissions error) and I'm not a fan of chocolatey. Scoop is the best option I've seen so far, but then there are issues like this :| Perhaps my expectations are too high from running a linux distro (debian for 16 years, gentoo for about 6 now) where the package manager is the backbone of the OS and never fails. Packages themselves may fail, but not the package manager.

[ArchGuyWu]

This is how MSYS2 deals with the similar thing(This update contains pacman itself.),we may learn something from this.

[fluffynuts]

There's a really, really, really simple solution: don't count on scoop. Just install pwsh via winget. Scoop should remove pwsh from the repos as it cannot be properly maintained via scoop itself.

[itpropro]

There's a really, really, really simple solution: don't count on scoop. Just install pwsh via winget. Scoop should remove pwsh from the repos as it cannot be properly maintained via scoop itself.

Right, this issue can be closed, as PowerShell can not only be installed by other third-party package managers and by WinGet, it can get updated by Windows Update.
Just handle pwsh as all other binaries should be handled: Don't install or update it with a package manager, if it has it's own update functionality.

[fluffynuts]

pwsh doesn't have it's own update facility - you must install via winget (or installer, and then use winget) to update.

to clarify: there is no way to ask pwsh to update itself (though this has been requested on their issues boards). You are required to use some kind of manager to do this, or manually download updates.

and, imo, it's not just that the issue should be closed - pwsh shouldn't be available in scoop repos because scoop can't update it

[itpropro]

At least on Windows, pwsh can and will be updated via. Windows Update, which will be sufficient for most users.
I don't think it needs to be removed, but a section in the docs about updating pwsh outside of the process itself should definitely be added.

[fluffynuts]

Windows Update won't update pwsh that was installed by scoop. If you want that to happen, you should install via that mechanism, or another, eg Winget. Since scoop cannot properly maintain pwsh as-is, it should be removed. Or the problem of properly supporting it via scoop should be revisited. As it is, it's a trap for the common user.

[fluffynuts]

This is precisely the energy that I mentioned the other day @rashil2000

Scoop is so close to being the perfect package manager, but it won't get there until the egos are knocked out of the equation. Meanwhile, modern systems are getting winget and you're losing your window of opportunity.

[rashil2000]

You're most welcome to contribute a fix if you want, it will get duly reviewed. Being snarky on the internet is not going to help anyone.

[fluffynuts]

I suggested fixes earlier and you made it quite clear that those approaches would not be considered. Submitting a PR seems like a colossal waste of time when I know that there's already going to be someone gate-keeping them out.

Your attitude towards issues I (and probably others) raise helps no-one. To wit:

• This issue isn't the first time I've been engaged in a conversation about pwsh
• Discord updated to portable edition, now opens multiple instances when invoked multiple times Extras#8383 (discord issues, where the "resolution" was "leave it broken")
• [email protected]: hash check failed Extras#8348 (which was just closed, without resolution)
• Looks like there's an automation to check and close bugs raised against hash failures, and it's not very helpful ): Extras#8350 (which was to re-raise the issue, closed again, without resolution)
  and another issue I raised, where scoop was failing to update itself or anything else, and the response was just "works for me" (I'm having trouble locating it, sorry).

At no point have I been "snarky". Frustated? For sure! Annoyed? Yes! Scoop (imo) literally has one job: to install and update packages. Yet consistently, I see you, @rashil2000, blocking issues which report to the contrary. I don't know why you do it, but it seems very clear to me that the scoop user experience is not of importance to you, which is a massive pity, because (a) scoop is so close to being the perfect package manager for windows (especially with user installs not requiring system-wide permissions) and (b) winget becoming the de-facto package manager on modern windows systems. You're facing the obsolescence of your project with a dogmatic DGAF approach.

[fluffynuts]

Whilst most people will just quietly drop usage, I'm (stupidly) mad at this whole state of affairs. I want scoop to succeed. I've been telling people for the last 2 years "use scoop". I've likened it to homebrew "but better". I've said stuff like "almost as good as a linux package manager" (and trust me, I've a lot of experience there). And yet, this.

[rashil2000]

• Re Discord and Autohotkey: The Discord and Autohotkey issues are moot: Discord has a bad history of updates and official installer is not compatible with Scoop, and the Autohotkey manifest had a bug which I fixed then and there.
• Re scoop update *: scoop update * not updating local bucket git repos Scoop#4936 is the issue. I'm hoping you can still realize that I can't fix something unless I can reproduce it.
• Re pwsh: The pwsh interaction is the only one where we disagreed.

At no point you have proposed a completely thought-out solution, you only threw around "ideas". I wouldn't have turned out those "ideas" had they been properly backed up.

but it seems very clear to me that the scoop user experience is not of importance to you, which is a massive pity

I would suggest you look at my contribution history before making such statements. Regardless, since you've already made that statement, perhaps you can help explain why I chose to spend time here?

[fluffynuts]

@rashil2000 I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.

I also release open-source software. One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.

As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing. Do you realise that most users don't report issues, but just go on with the assumption that the software sucks? That people who spend the time trying to report useful issues have spent their time, contributing to your project?

At no point you have proposed a completely thought-out solution

I did: the thought-out solution is to use the built-in powershell.exe instead of pwsh.exe, when powershell.exe is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated. Your response was that this wasn't acceptable, that powershell was going to die some day and pwsh was the future. Which it is, but a solution which works right now is better than no solution.

[rashil2000]

I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.

If you have no idea, refrain from speaking about it.

One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.

I'm a volunteer here; I don't have that much free time and I help out here for free.

As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing.

ScoopInstaller/Extras#8350 (comment) is exactly this.
As for this issue, @itpropro proposed updating docs in the manifest, which is precisely what I did to close it.

I did: the thought-out solution is to use the built-in powershell.exe instead of pwsh.exe, when powershell.exe is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated.

I hope you realize this wasn't my personal decision. There are other (much experienced) contributors in this project, who reviewed and agreed to the change (of using pwsh.exe in priority) before it was merged.

[fluffynuts]

I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.

If you have no idea, refrain from speaking about it.

You asked me a question about my perception of you. It feels like you don't care about UX from the way you respond to issues. I can't explain why tho. Guess I should just shut up and move on then, like most users who can't be bothered to report issues?

One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.

I'm a volunteer here; I don't have that much free time and I help out here for free.

Same! But I take the time to appreciate that people who spend time on discussions like this are giving the most precious thing they have: TIME. I can't get more of it, I don't know how much I have, and it's 100% finite.

As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing.

ScoopInstaller/Extras#8350 (comment) is exactly this. As for this issue, @itpropro proposed updating docs in the manifest, which is precisely what I did to close it.

Then say something. Closing out without a comment sends a clear message that you don't care about the time spent to report the issue.

I did: the thought-out solution is to use the built-in powershell.exe instead of pwsh.exe, when powershell.exe is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated.

I hope you realize this wasn't my personal decision. There are other (much experienced) contributors in this project, who reviewed and agreed to the change (of using pwsh.exe in priority) before it was merged.

Cool, but you also have the power to raise that you agree that it's a problem that could be solved, that there are ways to solve it, and to fight for the user in this instance. A team effort doesn't mean just letting go. Anyway, I don't think this discussion is going anywhere. I've spent enough time on this as it is. I really cared about trying to make things better, and I'm really sorry that I don't have the time to provide a PR - which may (or may not) have provided some support for my point of view.

At some point, one has to realise when to just throw in the towel, I guess?

[rmobis]

In case anyone ends up here looking for a solution (given this is the top result for scoop cant update pwsh), this is the excerpt from the manifes that contains the solution:

Since Scoop uses pwsh.exe internally, to update PowerShell Core itself, run scoop update pwsh from Windows PowerShell, i.e. powershell.exe.

[darthwalsh]

I've hit this issue again, see #5255. Repeating: the solution is to run scoop update pwsh from powershell.exe -- and not to use scoop.cmd!

[ylluminate]

This is still broken:

Seems only option is to:

$ winget install Microsoft.PowerShell
Found PowerShell [Microsoft.PowerShell] Version 7.4.2.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.4.2/PowerShell-7.4.2-win-x64.msi
  ██████████████████████████████   103 MB /  103 MB
Successfully verified installer hash
Starting package install...
Successfully installed

But even then Scoop is broken and cannot uninstall its own pwsh when winget's powershell is in execution following winget's is installation:

PowerShell 7.4.2
PS C:\Users\USERNAME> scoop uninstall pwsh
Uninstalling 'pwsh' (7.2.6).
ERROR The following instances of "pwsh" are still running. Close them and try again.

 NPM(K)    PM(M)      WS(M)     CPU(s)      Id  SI ProcessName
 ------    -----      -----     ------      --  -- -----------
     57    93.81      80.55       0.72    7304   1 pwsh

[darthwalsh]

@ylluminate the limitation of not being able to modify the file of a running EXE is not related to pwsh (this is a fundamental difference between Windows and *nix). There is a separate feature-request to allow installing the new version side-by-side with the old version, then update the current-version-junction sometime later, see ScoopInstaller/Scoop#3947 -- the same strategy should allow for uninstall.

Seems only option is to

If you choose to use scoop to manage pwsh, the workaround to upgrade pwsh.exe using powershell.exe is in the top-voted comment of this thread: #3572 (comment)

[mcunha]

In case anyone ends up here looking for a solution (given this is the top result for scoop cant update pwsh), this is the excerpt from the manifes that contains the solution:

Since Scoop uses pwsh.exe internally, to update PowerShell Core itself, run scoop update pwsh from Windows PowerShell, i.e. powershell.exe.

For users choosing to automate this ahead of doing a scoop update - run the the following by hand via Win + R or from cmd.exe:

powershell -Command "scoop update pwsh"

I'll submit a PR to improve the guidance. I missed that wiz's PR #5712 does exactly this.

[Navirl]

If "Windows Terminal" is installed, the update fails because pwsh.exe is executed when powershell.exe is run.
When PowerShell is run as administrator, it starts without the Windows terminal, so the update could be done with scoop update pwsh.