Repository navigation
PowerShell Scripts require .ps1 extension #1103
Description
Scripts (on linux) don't function unless they have the extension .ps1 (generally, languages do not require specific extensions in Linux when using shebang to start them #! /usr/bin/powershell
Steps to reproduce
File: myscript
#!/usr/bin/powershell
echo hichmod a+x ./myscript
# hangs!
./myscript
mv ./myscript ./myscript.ps1
# works
./myscript.ps1
hi
Expected behavior
On linux, this should work even if the extension isn't .ps1
Actual behavior
EDIT
it turns out it didn't hang, it fails:
System.TypeInitializationException: The type initializer for 'System.Management.Automation.PSVersionInfo' threw an exception. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Reflection.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An internal error occurred.
(Exception from HRESULT: 0x8007054F)
at System.Reflection.Internal.LightUpHelper.GetMethod(Type type, String name, Type[] parameterTypes)
at System.Reflection.Internal.MemoryMapLightUp.TryLoadMembers()
at System.Reflection.Internal.MemoryMapLightUp.get_IsAvailable()
at System.Reflection.Internal.StreamMemoryBlockProvider..ctor(Stream stream, Int64 imageStart, Int32 imageSize, Boolean isFileStream, Boolean leaveOpen)
at System.Reflection.PortableExecutable.PEReader..ctor(Stream peStream, PEStreamOptions options, Nullable`1 sizeOpt)
at System.Diagnostics.FileVersionInfo.TryLoadManagedAssemblyMetadata()
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at System.Management.Automation.PSVersionInfo.GetBuildVersion()
at System.Management.Automation.PSVersionInfo..cctor()
--- End of inner exception stack trace ---
at System.Management.Automation.PSVersionInfo.get_PSVersion()
at System.Management.Automation.PSSnapInReader.ReadRegistryInfo(Version& assemblyVersion, String& publicKeyToken, String& culture, String& architecture, String& applicationBase, Version& psVersion)
at System.Management.Automation.PSSnapInReader.ReadCoreEngineSnapIn()
at System.Management.Automation.Runspaces.InitialSessionState.ImportCorePSSnapIn()
at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault2()
at Microsoft.PowerShell.UnmanagedPSEntry.Start(String consoleFilePath, String[] args, Int32 argc)
at Microsoft.PowerShell.ManagedPSEntry.Main(String[] args)
Environment data
v0.4.0
Activity
andyleejordan commentedon Jun 16, 2016
To be discussed at next usability sync.
giggio commentedon Aug 19, 2016
This is really important. Without this we also can't use scripts as executables, as adding a shebang to the start of a file without a
.ps1extension will fail.This completely breaks the way we work on Linux. On Windows it is fine, we are used to it, on Linux it is just wrong to require the extension.
4 remaining items
SteveL-MSFT commentedon Dec 1, 2016
I completely understand that the extension is not how Linux works, but wouldn't this encourage non-cross platform PS Scripts?
RamblingCookieMonster commentedon Dec 2, 2016
I don't think that's necessarily a bad thing - sure, functions and modules should make considerations for cross platform compatibility, but some of these, and some scripts that leverage them, will inherently target specific platforms.
IMHO, you might find the folks writing PowerShell scripts on *nix, or at least a decent proportion of them, recognize the importance of cross-platform support, where it makes sense.
That said, assuming I'm wrong, wouldn't it be better to have a few folks end up writing non-cross-platform scripts (assumption), rather than walking away from the language given this limitation (assumption, perhaps just as likely)?
Cheers!
SteveL-MSFT commentedon Dec 2, 2016
Warren Frame (@RamblingCookieMonster) I'm personally where you landed on this which is to lower the barrier to entry on Linux to get adoption and where cross platform is needed, scriptanalyzer can help with that and those users will learn very quickly it won't work on Windows.
SteveL-MSFT commentedon Dec 8, 2016
@PowerShell/powershell-committee discussed this. There may be impact to get-command as now it would have to read the shebang to determine if it's a PowerShell script so we can run it within current runspace. It may be worth experimenting to compare perf impact.
We should fix the hang so that scripts without extensions works as "executables" (new instance of powershell will execute it) as long as shebang is there.