-
Notifications
You must be signed in to change notification settings - Fork 8
alda update
prompt no longer works
#35
Comments
elyisgreat writes:
PS C:\Users\elyis> powershell -Command Invoke-WebRequest -Uri "https://github.com/alda-lang/alda/releases/downlo
ad/1.0.0-rc82/alda.exe" -OutFile "C:\Program Files (x86)\Alda\alda.exe"
x86 : The term 'x86' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:123
+ ... s/download/1.0.0-rc82/alda.exe -OutFile C:\Program Files (x86)\Alda\a ...
+ ~~~
+ CategoryInfo : ObjectNotFound: (x86:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
This is a very weird error, I wonder why it's throwing a command not found
error for text inside a string. This is probably some feature or parsing
behaivor of PowerShell that I'm overlooking. I'm guessing this is related to
having the 'x86' in parens. Maybe single quoting would be better (as it is in
bash).
Invoke-WebRequest : The request was aborted: Could not create SSL/TLS secure channel.
At line:1 char:1
+ Invoke-WebRequest -Uri "http://github.com/alda-lang/alda/releases/dow ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest]
, WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestComm
and
My best guess for this is something wrong with the certificates on your
system.
This could also be a change to the 'Invoke-WebRequest' command syntax though
or something else.
I don't have access to any windows machines anymore, so I'm unable to help
debug this...
If you can find a working command, it should be easy to update the prompt to
print out something that works.
|
Hi @elyisgreat , I agree with @jgkamat. I was already looking at the reported issue (actually, two sub-issues are present), and I've found that the first sub-issue (x86) is avoidable trough single quoting, as per @jgkamat's suggestion, but also needs the command to be embraced in graph brackets. This the working version: For what concerns the certificate error, you need to ensure you have Tls12 listed in [Net.ServicePointManager]::SecurityProtocol, which defines the cryptography protocols allowed by your client. From PowerShell, run:
This is my real output: as you can see, I had no Tls version 1.2 enabled, thus I got your very same error. My Powershell details:
You can solve it just by adding Tls12 value to that list. To do so, you'll need to assign to the SecurityProtocol variable a list consisting of its current values plus the new one(s) you want to add. So, in my case:
Then check the list is correct (must contain previous values + Tls12):
I was looking for a way to just append to the current list, without needing to fully re-definite it by adding again its current values too, but didn't succeed. If someone has better luck at this please drop a line. Quick recap |
Oh yes, sorry: the single quotes are actually not needed (even thought they are more proper in this case since there's no variable to evaluate). I've just noted that the changes to SecurityProtocol are only session-scoped and not permanent. Thus, you'll need to invoke the command from the very same PowerShell session where you've modified SecurityProtocol. So, recapping:
HTH |
I noticed that. My above photo depicts a single session. Interestingly, after updating the SecurityProtocol, running
creates an error, but running
works normally. |
Exactly: invoking powershell -Command creates a separate session with its own context, whose lifetime boundaries are defined by the execution of the given command, and is not even needed in this case since we're directly executing from the PowerShell environment. Unfortunately, I can't help users experiencing this issue from cmd.exe (you will need to launch a powershell to issue such update command). In case a user can't use Powershell, he/she will need to manually download the file, then autonomously replace the existing one in their Alda directory. |
Maybe it would make sense for the Alda CLI to provide two separate commands that Windows users can run, depending on if they're using cmd.exe or PowerShell? |
works as a one-liner for me! Unfortunately, it seems to work only in instances of PowerShell and not in cmd.exe (Of course this is all assuming the server is already down). |
Can we update the Windows update prompt so that it says
instead of
? |
@elyisgreat Does that only work when run in PowerShell? If so, I'm still thinking that it might be best if we included 2 commands, one for cmd.exe and one for PowerShell. On another note: that command is soooo long! It looks like PowerShell supports breaking up input over multiple lines, so perhaps we can do something like this for better readability? powershell `
-Command {[Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Ssl3 `
-bor [System.Net.SecurityProtocolType]::Tls `
-bor [System.Net.SecurityProtocolType]::Tls12 ; `
Invoke-WebRequest `
-Uri "https://github.com/alda-lang/alda/releases/download/<version>/alda.exe" `
-OutFile "C:\Program Files (x86)\Alda\alda.exe"} |
Yea, but doesn't the old one have the same problem? |
I don't think so. I think the existing one can be run in cmd.exe and it leverages |
@elyisgreat that one-liner looks great to me! Good job! In July I did reach that solution too, sorry I didn't post it, but then got stuck at having it work from cmd.exe too - too high effort-to-improvement ratio job for my skills, so I gave up. That's a pity since most Windows users won't use Powershell. @daveyarwood note that the line splitting will only work from native powershell - if you launch powershell from cmd.exe then launch the command it won't work instead. |
Ah, that's a bummer. I guess we can't make it multi-line, then. I'd still like to see a version that works for cmd.exe and a version that works for Powershell. Is it the case that we could keep the current version as the one that works for cmd.exe, and use the new one @elyisgreat posted as the one that works for Powershell? |
@daveyarwood AFAIK there's currently no version working on cmd.exe. Maybe I'm missing something? |
Oh, I think I misunderstood! So, I think what we should do, then, is to provide this new, improved version that works in Powershell, and make it clear that this will work if you're running Powershell, otherwise, you can manually download and install the latest release (which we're already including a link for). |
I'm fine with the single-line version. It sounds like the multi-line version is more trouble than it's worth. If one of you would like to put together a PR, I'll happily merge it and include it with the next release of Alda! |
PR submitted on that same day, sorry for forgetting to link it to this issue. I've stumbled upon Chocolatey, a package manager for Windows. Looks like it's gaining a relevant user base (i.e., NodeJS installer will propose to install it too). This would add a layer, but would also enhance user experience. |
Chocolatey looks promising - definitely worth exploring for managing Alda updates on Windows. I'm not seeing a PR that makes the change we discussed above. Are you sure you submitted one? |
I think I've figured out how to make I'm planning to experiment with this and see if I can get it working in a Windows CI environment. If it works, the experience will be way better for Windows users. I'm going to go ahead and close this issue, since it's Alda v1 specific and Alda v2 will be out soon 🤞 |
Attempting to update via the suggested prompt no longer works.
The text was updated successfully, but these errors were encountered: