PowerShell Scripts require .ps1 extension

[fearthecowboy]

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 hi

chmod 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

[andschwa]

To be discussed at next usability sync.

[giggio]

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 .ps1 extension 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.

[SteveL-MSFT]

I completely understand that the extension is not how Linux works, but wouldn't this encourage non-cross platform PS Scripts?

[RamblingCookieMonster]

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]

@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]

@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.