Closed gerlinl closed 3 years ago
I finally understand what's causing this issue, but only has of yet a couple of ideas on how to either fix it, or at least create a workaround. It shouldn't take me long to publish up a solution.
Possible solutions:
env
and perl
in the ftype
BERRYBREWPERL
, and set it as a user env var when the user switches perls, then in ftype
, instead of env perl...
, do %BERRYBREWPERL%\perl ...
. This approach may allow us to remove using the env
binary entirely. If not, at least in this context.Tentative solution that appears to work, at least manually:
%BERRYBREW_PERL%
user env var to whatever the binPath
is for the current Perl, plus \perl.exe
reg_expand_sz
(expandable string type) so that we can populate it with an environment varHKCR\berrybrewPerl\shell\open\command
default entry to %BERRYBREW_PERL% %1 %*
%BERRYBREW_PERL%
user env var so that berrybrewPerl
assoc takes effect, whether in Switch()
or somewhere else. No call to FileAssoc()
will be necessary if the actual association itself isn't changingftype
, but that's probably overkillAnother idea to think about is to hard code the absolute path in the reg value instead of the env var in Switch()
. This way, a new prompt won't be required.
When running a perl command from a cmd prompt, no results are displayed until I push \<ENTER> a second time.
For example I have a simple test script that list the perl info and displays the first passed argument:
When it is run from a command prompt I get this:
The curser is blinking after the second W:> just like it has completed.
However if I push \<ENTER> again, I see the results of the script:
I then need to push \<ENTER> again to get back to a command prompt.
If I unset the association feature this does not happen (though of course the association is not handled within BB)
I don't think this would be expected behavior, it makes it difficult to run and test complicated scripts.
This is a new install of BB 1.31 on Windows 10 using the downloaded installer.