CODEWITHSUNDEEP
powershellcygwin
MatrixManAtYrService
MatrixManAtYrService

Reputation: 9131

Why would a powershell script behave differently if it was called from Cygwin?

ls I typically run powershell scripts from cygwin like this:

$ powershell ./scriptname.ps1

It usually works well, but today I found an instance where a script fails when called from Cygwin, but succeeds when called from powershell. I have a very similar script that succeeds in both cases.

This script works both ways:

buildOpenSSL32.ps1

param ([string]$prefix = $(Resolve-Path .))
$adjPrefix = $prefix -replace "\\",  "/"
$prefix32 = "${adjPrefix}/win32"
New-Item -ErrorAction Ignore -ItemType directory -Path $prefix32
pushd ${prefix32}/openssl-1.0.2j
write-host "Building OpenSSL for x86 into $prefix32 ..."
write-host "Configuring..."
perl Configure debug-VC-WIN32 --prefix=$prefix32
ms\do_nasm
write-host "Building..."
cmd /c "`"${env:VS140COMNTOOLS}vsvars32.bat`" && nmake /f ms\nt.mak && nmake /f ms\nt.mak install"
popd
write-host "...Done building OpenSSL for x86"

This script works when called from powershell directly, but fails wen called from Cygwin:

buildOpenSSL64.ps1

param ([string]$prefix = $(Resolve-Path .))
$adjPrefix = $prefix -replace "\\",  "/"
$prefix64 = "${adjPrefix}/win64"
New-Item -ErrorAction Ignore -ItemType directory -Path $prefix64
pushd ${prefix64}/openssl-1.0.2j
write-host "Building OpenSSL for x64 into $prefix64 ..."
write-host "Configuring..."
perl Configure debug-VC-WIN64A --prefix=$prefix64
ms\do_win64a
write-host "Building..."
cmd /c "`"${env:VS140COMNTOOLS}../../VC/vcvarsall.bat`" amd64 && nmake /f     ms\nt.mak && nmake /f ms\nt.mak install"
popd
write-host "...Done building OpenSSL for x64"

The error looks like this:

C:\cygwin64\home\mrixman\OpenSSL5\win64\openssl-1.0.2j>perl ms\uplink-x86_64.pl nasm  1>ms\uptable.asm
Can't open perl script "ms../crypto/perlasm/x86_64-xlate.pl": No such file or directory

Why would they care how the script invocation was handled?

Edit:

Based on where the error appears, the relevant difference in the above scripts appears to be ms\do_nasm vs ms\do_win64a

do_nasm.bat (cygwin friendly)

perl util\mkfiles.pl >MINFO
perl util\mk1mf.pl nasm VC-WIN32 >ms\nt.mak
perl util\mk1mf.pl dll nasm VC-WIN32 >ms\ntdll.mak
perl util\mk1mf.pl nasm BC-NT >ms\bcb.mak

perl util\mkdef.pl 32 libeay > ms\libeay32.def
perl util\mkdef.pl 32 ssleay > ms\ssleay32.def

do_win64a.bat (error when grandparent shell is cygwin)

perl util\mkfiles.pl >MINFO

cmd /c "nasm -f win64 -v" >NUL 2>&1
if %errorlevel% neq 0 goto ml64

perl ms\uplink-x86_64.pl nasm > ms\uptable.asm   # <-- This line
nasm -f win64 -o ms\uptable.obj ms\uptable.asm
goto proceed

:ml64
perl ms\uplink-x86_64.pl masm > ms\uptable.asm
ml64 -c -Foms\uptable.obj ms\uptable.asm

:proceed
perl util\mk1mf.pl VC-WIN64A >ms\nt.mak
perl util\mk1mf.pl dll VC-WIN64A >ms\ntdll.mak

perl util\mkdef.pl 32 libeay > ms\libeay32.def
perl util\mkdef.pl 32 ssleay > ms\ssleay32.def

Edit 2:

I created a script that calls Get-ChildItem Env: So we can look at how the powershell environment differs when it's called from Cygwin (broken) when compared to how it looks when run from my start menu (working). I converted everything to lowercase so that the case sensitivity mismatch doesn't cause a problem.

Get-ChildItem Env: diff

Upvotes: 2

Views: 249

Answers (1)

Jamie Kemp
Jamie Kemp

Reputation: 46

For anyone who stumbles across this post looking for a answer. It is very likely you have both cygwin (or similar) perl on the path before ActivePerl.

Having been looking into this for a while, I only considered it being conflicting versions of perl when I found this comment and the two previous comments regarding version output on the openssl bug tracker. Hopefully this might save others some time.

Upvotes: 2

Related Questions