Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Monday, July 03, 2017 9:24 PM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: powershell compatible SPP The idea is an SPP that uses PowerShell to function and can operate on a system without cmd.exe, command.com, or batch files. Aaah ... sorry, I failed to grasp that. I don't have much interest in such a thing, after all ;-) Good luck with it, though. Cheers, Rob
Re: powershell compatible SPP
On 7/3/2017 00:36, sisyph...@optusnet.com.au wrote: -Original Message- From: Chris Marshall Sent: Sunday, July 02, 2017 1:32 AM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: powershell compatible SPP But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? The main one is without command.com, all the .bat files for running perl scripts as programs (think pdl2 or perldl) won't run. They run ok for me in the powershell - in so far as they start up fine and I can run simple scripts on them. (Or do people want to be able to run cmdlets in the pdl2 shell ?) Now, disable cmd.exe on the windows system and run the test again. The idea is an SPP that uses PowerShell to function and can operate on a system without cmd.exe, command.com, or batch files. One thing I did notice is that the history (up/down arrow) keys don't work in the perldl shell that's run in powershell, though those keys work when the perldl shell is run in the cmd.exe shell. When I switched to using pdl2, the history keys then became functional. Anyway I think your main aim at this point was to gauge the level of interest in your proposed project, and although I'm not prepared to commit to the project, I do find it a bit interesting and would like to stay up to date with developments. Are there more detailed reports (that I can access) of the actual problems being experienced ? The problem is SPP doesn't run without cmd.exe and batch file support on a PC. The goal is to be able to use a native windows perl (SPP) when only PowerShell is available. ATM, cygwin perl is an option for these conditions but the emulation of POSIX makes for a bit of a performance hit. Cheers, Chris
Re: powershell compatible SPP
-Original Message- From: sisyph...@optusnet.com.au Sent: Monday, July 03, 2017 2:36 PM To: win32-vanilla@perl.org ; Chris Marshall Subject: Re: powershell compatible SPP When I switched to using pdl2, the history keys then became functional. Duh not correct. But if, in the powershell, I do: $env:term="" then history keys work as expected in both perldl and pdl2 shells. Cheers, Rob
Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Sunday, July 02, 2017 1:32 AM To: sisyph...@optusnet.com.au ; win32-vanilla@perl.org Subject: Re: powershell compatible SPP But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? The main one is without command.com, all the .bat files for running perl scripts as programs (think pdl2 or perldl) won't run. They run ok for me in the powershell - in so far as they start up fine and I can run simple scripts on them. (Or do people want to be able to run cmdlets in the pdl2 shell ?) One thing I did notice is that the history (up/down arrow) keys don't work in the perldl shell that's run in powershell, though those keys work when the perldl shell is run in the cmd.exe shell. When I switched to using pdl2, the history keys then became functional. Anyway I think your main aim at this point was to gauge the level of interest in your proposed project, and although I'm not prepared to commit to the project, I do find it a bit interesting and would like to stay up to date with developments. Are there more detailed reports (that I can access) of the actual problems being experienced ? Cheers, Rob
Re: powershell compatible SPP
On 6/30/2017 23:54, sisyph...@optusnet.com.au wrote: -Original Message- From: Chris Marshall Sent: Saturday, July 01, 2017 5:16 AM To: win32-vanilla@perl.org Subject: powershell compatible SPP Hi Chris, Following a conversation with Chas Owens at YAPC::NA 2017 in Alexandria, we're working on an implemention of SPP using Windows PowerShell rather than command.com and .bat files. On a Windows 10 laptop, I opened a powershell (for the first time in my life) and added the location of SPP's gcc and perl bin folders to the path: PS C:\p> $Env:Path="$Env:Path;C:\_64\strawberry5.24.0-ld\c\bin;C:\_64\strawberry5.24.0-ld\perl\bin" (I'm not proposing that as the solution - I would think you'd want to provide an alternative to portableshell.bat that does that for the user.) Yes, something like portableshell.ps1 But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? The main one is without command.com, all the .bat files for running perl scripts as programs (think pdl2 or perldl) won't run. I was thinking to replace the batch files with PowerShell functions (or cmdlets as they call them). It seemed fine to me - whereas running SPP's portableshell.bat from inside an already existing powershell seemed to bugger up the shell's behavioural characteristics. Can't run .bat files wihout a command.com. I'm hoping for a next generation portable shell dot bat. Cheers, Chris
Re: powershell compatible SPP
-Original Message- From: Chris Marshall Sent: Saturday, July 01, 2017 5:16 AM To: win32-vanilla@perl.org Subject: powershell compatible SPP Hi Chris, Following a conversation with Chas Owens at YAPC::NA 2017 in Alexandria, we're working on an implemention of SPP using Windows PowerShell rather than command.com and .bat files. On a Windows 10 laptop, I opened a powershell (for the first time in my life) and added the location of SPP's gcc and perl bin folders to the path: PS C:\p> $Env:Path="$Env:Path;C:\_64\strawberry5.24.0-ld\c\bin;C:\_64\strawberry5.24.0-ld\perl\bin" (I'm not proposing that as the solution - I would think you'd want to provide an alternative to portableshell.bat that does that for the user.) But does that provide the functionality that's required ? ... or are there some issues regarding the functionality thus obtained ? It seemed fine to me - whereas running SPP's portableshell.bat from inside an already existing powershell seemed to bugger up the shell's behavioural characteristics. Cheers, Rob