New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PowerShell Scripts require .ps1 extension #1103

Closed
fearthecowboy opened this Issue Jun 14, 2016 · 6 comments

Comments

@fearthecowboy

fearthecowboy commented Jun 14, 2016

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 andschwa added this to the Aug17 milestone Jun 16, 2016

@andschwa

This comment has been minimized.

Show comment
Hide comment
@andschwa

andschwa Jun 16, 2016

Member

To be discussed at next usability sync.

Member

andschwa commented Jun 16, 2016

To be discussed at next usability sync.

@andschwa andschwa added the Usability label Jun 16, 2016

@ealexjordan ealexjordan self-assigned this Jun 22, 2016

@andschwa andschwa referenced this issue Jul 18, 2016

Open

Unix usability problems #1390

5 of 11 tasks complete

@HemantMahawar HemantMahawar modified the milestones: Aug17, Future Jul 20, 2016

@vors vors removed the cut-aug17 label Jul 21, 2016

@giggio

This comment has been minimized.

Show comment
Hide comment
@giggio

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

giggio commented 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 .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

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Dec 1, 2016

Member

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

Member

SteveL-MSFT commented 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

This comment has been minimized.

Show comment
Hide comment
@RamblingCookieMonster

RamblingCookieMonster 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!

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

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Dec 2, 2016

Member

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

Member

SteveL-MSFT commented Dec 2, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@SteveL-MSFT

SteveL-MSFT Dec 8, 2016

Member

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

Member

SteveL-MSFT commented 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.

@SteveL-MSFT SteveL-MSFT moved this from Completed to Done in Linux/Mac Usability Mar 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment