in reply to New berrybrew installer; Looking for testers

Thanks for doing this. Here are my observations of the process.

Windows 10 Pro, version 1903, OS Build 18362.476

Note: I have an existing berrybrew installation, and this seems not to be expected by the installer.


Symantex Download Insight ate the file. After extraction from quarantine it ran.

I saw one cmd window flash past.

The second window ran the strawberry perl download. (This takes a little while, so a download progress indicator or spinner would be nice).

Once that completed a few more cmd windows flashed past.

On opening a clean cmd window I ran echo %PATH%. The strawberry perl instance is in the path at the front, but the newly installed berrybrew is not.

berrybrew version 1.22 "c:\Program Files (x86)\berrybrew\bin\berrybrew.exe" version 1.27

So it seems to have done everything except put berrybrew itself in the path. Note that I have not tried rebooting to see if it gets picked up that way.

On uninstall it removes the c:\program files(x86)\berrybrew folder. The strawberry perl it installed is still there. It has, however, removed my pre-existing berrybrew from the path.

Replies are listed 'Best First'.
Re^2: New berrybrew installer; Looking for testers
by stevieb (Canon) on Nov 23, 2019 at 00:07 UTC

    Thank you for this.

    I should have made note about previous installs.

    A side effect I didn't consider is that internally, I call berrybrew unconfig but not using the full path, so it likely used the existing 1.22 berrybrew, which would have blown away the original PATH. Probably that's the reason the new path wasn't added as well.

    Was there any indication as to why the malware software caught it? I don't use Windows except for developing berrybrew and testing things for a few Windows-based clients I have.

    If your 1.22 version was using C:\berrybrew as its Perl instance directory, re-adding that version to PATH should fix things right up. If you want to carry on with the new version, it will happily use your old instances, or the new 5.30.0 instance you installed as part of the test (using berrybrew switch $version). The new 1.27 is backwards compatible with 1.22. It just has many new features and error checking.

    I'm still working out kinks. This is my first time creating a Windows installer :)

    Again, thanks. Very helpful feedback.

      The AV issues are mostly time related. Once a few users have reported the exe it should be sorted.

      Some key details from the log:

      There is not enough information about this file to recommend it. This file has been seen by no Symantec users. Symantec has known about this file approximately 2 days.

      I re-added the older berrybrew to the path and it worked again so that part is corrected.

      I then ran berrybrew upgrade, and now I get this error. I had to revert the changes to the perls.json file in the git repo for it to work (this is not new). I don't imagine this is due to the installer, and is more likely something else in the development process, or how I have things set up.

      berrybrew version Unhandled Exception: System.ArgumentException: Item has already been a +dded. Key in dictionary: '5.26.2_64_PDL' Key being added: '5.26.2_64 +_PDL' at System.Collections.Hashtable.Insert(Object key, Object nvalue, B +oolean add) at System.Collections.Specialized.OrderedDictionary.Add(Object key, + Object value) at BerryBrew.Berrybrew.PerlGenerateObjects(Boolean importIntoObject +) at berrybrew.Bbconsole.Main(String[] args)


      I ran a git pull on the repo and the issue has now gone away. The issue was perhaps something to do with berrybrew upgrade and git.

        That's all great information. Thank you.

        I do know about some issues regarding upgrading, and that's next on my roadmap to clean up.

        Since there are some issues with older versions and 'unconfig', in the installer, I'm just going to check if there's a berrybrew installed, warn the user on what to do so they can proceed. I'm not going to make changes to the system; I'm going to let the user do that if necessary. Better safe than sorry.

Re^2: New berrybrew installer; Looking for testers
by stevieb (Canon) on Nov 23, 2019 at 00:20 UTC

    I installed berrybrew 1.22 on a vanilla win10 VM, installed and switched to Perl 5.10.1_32, then ran the new installer.

    I have made some changes to the installer after the OP (you can get it here.

    Here's the result of those actions:

    C:\Program Files\Mono>echo %path% C:\Program Files\Mono\bin\;C:\berrybrew\5.30.0_64\c\bin;C:\berrybrew\5 +.30.0_64\perl\bin;C:\berrybrew\5.30.0_64\perl\site\bin;C:\Windows\sys +tem32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Windows +PowerShell\v1.0\;C:\Program Files\Git\cmd;c:\Users\admin\Downloads\be +rrybrew\berrybrew-1.22\bin;C:\Program Files (x86)\berrybrew\bin

    So the new path gets installed *after* the old one. I will add some checks and throw a warning window to state that the old berrybrew will be disabled if they proceed, and I'll write a routine to automatically register any custom or virtual perls they may have had installed in the old version. If the user decides not to proceed, I'll just abort the setup.