Bug #88062 for local-lib: Add support for Windows PowerShell

Fri Aug 23 10:15:10 2013 MPERRY [...] cpan.org - Ticket created

Subject:

Add support for Windows PowerShell

local::lib assumes that it's running under the legacy cmd.exe rather than PowerShell when used on Windows systems. Given that PowerShell is the recommended command line environment for Windows users, local::lib should assume that it's running on PowerShell when $^O eq 'MSWin32' unless it can detect otherwise. perl -Mlocal::lib should provide output that looks similar the following when executed from within PowerShell. $env:PERL_LOCAL_LIB_ROOT = "$env:PERL_LOCAL_LIB_ROOT;C:\Users\joeaverage\perl5" $env:PERL_MB_OPT = "--install_base C:\Users\joeaverage\perl5" $env:PERL_MM_OPT = "INSTALL_BASE=C:\Users\joeaverage\perl5" $env:PERL5LIB = "C:\Users\joeaverage\perl5\lib\perl5;$env:PERL5LIB" $env:PATH = "C:\Users\joeaverage\perl5\bin;$env:PATH" Environment variables for PowerShell differ from cmd.exe in the following ways. 1. Environment variables are prefixed with '$env:' 2. Optional spaces can appear on either side of the assignment operator. I've added them in the example above for readability's sake. 3. The value to be assigned must be quoted since it will contain semicolons which is a command separator The Win32 API could be used to check the parent process. Shell::Guess implements a small subroutine that uses Win32::Process::Info to get the parent process name. Maybe that code can be harvested to do the minimal checking needed for local::lib to see if it's being called from cmd.exe. In the documentation it should be mentioned that the user can execute the following to make the variables are set by their shell startup script (provided they have one). echo 'perl -Mlocal::lib | % { iex $_ }' >>$PROFILE I'd be happy to help out with any questions on how to fix this bug. I'm not sure I know enough to make the fix myself without mentoring. Email me if that's something you'd prefer to do.

Fri Aug 23 12:19:55 2013 apeiron [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88062] Add support for Windows PowerShell
Date:	Fri, 23 Aug 2013 12:19:39 -0400
To:	Matt Perry via RT <bug-local-lib [...] rt.cpan.org>
From:	Chris Nehren <apeiron [...] cpan.org>

On Fri, Aug 23, 2013 at 10:15:12 -0400, Matt Perry via RT wrote: Show quoted text

> Fri Aug 23 10:15:10 2013: Request 88062 was acted upon. > Transaction: Ticket created by MPERRY > Queue: local-lib > Subject: Add support for Windows PowerShell > Broken in: 1.008011 > Severity: Normal > Owner: Nobody > Requestors: MPERRY@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=88062 > > > local::lib assumes that it's running under the legacy cmd.exe rather than > PowerShell when used on Windows systems. Given that PowerShell is the > recommended command line environment for Windows users, local::lib should > assume that it's running on PowerShell when $^O eq 'MSWin32' unless it can > detect otherwise.

If we're going to optimize that way, I'd like to see some evidence that it is indeed the most common case. Show quoted text

> The Win32 API could be used to check the parent process. Shell::Guess > implements a small subroutine that uses Win32::Process::Info to get the > parent process name. Maybe that code can be harvested to do the minimal > checking needed for local::lib to see if it's being called from cmd.exe.

Could be workable. Show quoted text

> In the documentation it should be mentioned that the user can execute the > following to make the variables are set by their shell startup script > (provided they have one). > > echo 'perl -Mlocal::lib | % { iex $_ }' >>$PROFILE > > I'd be happy to help out with any questions on how to fix this bug. I'm not > sure I know enough to make the fix myself without mentoring. Email me if > that's something you'd prefer to do.

Most of the local::lib maintainers avoid Windows (especially the modern versions) so we're generally not very clued about it. We've always taken the "patches welcome" approach for feature requests and bug reports. Perhaps one of the Windows users on the comaint list (Mithaldu?) can be more useful. -- Chris Nehren

Fri Aug 23 12:19:57 2013 The RT System itself - Status changed from 'new' to 'open'

Fri Aug 23 17:25:33 2013 haarg [...] haarg.org - Correspondence added

I just checked the environment variables available when running under PowerShell (on Windows XP). PSMODULEPATH is the only variable I can see that could identify it. Everything else matches cmd.exe. It might be a better approach to add an import option to be explicit about the shell you want to use. I highly doubt PowerShell use is more common than cmd.exe.

Fri Aug 23 19:29:55 2013 MPERRY [...] cpan.org - Correspondence added

Chris and Graham, Thanks for the feedback. I have some more homework to do on this. On Fri Aug 23 14:25:33 2013, haarg wrote: Show quoted text

> I just checked the environment variables available when running under > PowerShell (on Windows XP). PSMODULEPATH is the only variable I can > see that could identify it. Everything else matches cmd.exe.

That won't work. PSModulePath is a system environment variable, so it's going to be visible both inside and outside of PowerShell. I compared the environment variables from within PowerShell (on Win7) and cmd.exe and the only difference was cmd.exe had an additional variable called PROMPT with a value of "$P$G". From within PowerShell, the $PSVersionTable hashtable contains information about the running PowerShell process, but it's an automatic variable, not an environment variable so it won't be visible to Perl. PowerShell has four types of variables, but only environment variables are visible outside of PowerShell as far as I know. Show quoted text

> It might be a better approach to add an import option to be explicit > about the shell you want to use.

That sounds acceptable and might be the best option. If I'm able to add this functionality, what's the preferred way to contribute a patch? Should I make a patch file with git and attach it here or is there some other way? I'm new to this. Show quoted text

> I highly doubt PowerShell use is more common than cmd.exe.

Would that be for Windows Perl programmers or all Windows users? I realize now that my original post was biased. I'm a Windows sysadmin who uses Perl as opposed to a Perl programmer who uses Windows. No one uses cmd.exe in my professional circles for several years now. I thought it had disappeared almost everywhere.

Fri Nov 08 20:13:54 2013 haarg [...] haarg.org - Correspondence added

On Fri Aug 23 19:29:55 2013, MPERRY wrote: Show quoted text

> Chris and Graham, > Thanks for the feedback. I have some more homework to do on this. > > On Fri Aug 23 14:25:33 2013, haarg wrote:

> > I just checked the environment variables available when running under > > PowerShell (on Windows XP). PSMODULEPATH is the only variable I can > > see that could identify it. Everything else matches cmd.exe.

> > That won't work. PSModulePath is a system environment variable, so > it's going to be visible both inside and outside of PowerShell. I > compared the environment variables from within PowerShell (on Win7) > and cmd.exe and the only difference was cmd.exe had an additional > variable called PROMPT with a value of "$P$G".

Ah, I missed that. I don't really like checking PROMPT, but I'll check into that a little more. Show quoted text

> > From within PowerShell, the $PSVersionTable hashtable contains > information about the running PowerShell process, but it's an > automatic variable, not an environment variable so it won't be visible > to Perl. PowerShell has four types of variables, but only environment > variables are visible outside of PowerShell as far as I know. >

> > It might be a better approach to add an import option to be explicit > > about the shell you want to use.

> > That sounds acceptable and might be the best option. If I'm able to > add this functionality, what's the preferred way to contribute a > patch? Should I make a patch file with git and attach it here or is > there some other way? I'm new to this.

I already have a patch for this, although it's part of larger patch series. Hopefully it will be merged soon. I also wrote up a routine that detects the parent process to do autodetection of cmd.exe vs powershell.exe. I'm not entirely sure if I want to use this code though. Show quoted text

> > I highly doubt PowerShell use is more common than cmd.exe.

> > Would that be for Windows Perl programmers or all Windows users? I > realize now that my original post was biased. I'm a Windows sysadmin > who uses Perl as opposed to a Perl programmer who uses Windows. No one > uses cmd.exe in my professional circles for several years now. I > thought it had disappeared almost everywhere.

It probably doesn't matter much. Given backwards compatibility issues, the number of windows xp systems out there that didn't ship with powershell, and non-sysadmin programmers, I don't think changing the default is a good idea. So having working autodetection or specifying using a parameter are going to be the ways forward.

Sun Dec 22 21:58:25 2013 haarg [...] haarg.org - Correspondence added

I've gone ahead with using the PROMPT variable to detect the difference between cmd and powershell. The parent process routine I wrote was too complex for my liking. I also added the --shelltype option so the shell can be chosen explicitly. Included in dev release 2.000_000.

Sun Dec 22 21:58:25 2013 haarg [...] haarg.org - Status changed from 'open' to 'patched'

Mon Dec 30 16:21:23 2013 haarg [...] haarg.org - Correspondence added

Resolved in 2.000003

Mon Dec 30 16:21:25 2013 haarg [...] haarg.org - Status changed from 'patched' to 'resolved'

Mon Dec 30 16:21:26 2013 haarg [...] haarg.org - Fixed in 2.000003 added