.NET Framework - Why ".PS1" file extension for PS scripts?

Asked By Larry__Weiss

20-Feb-09 07:12 PM

Does the "1" in the .PS1 extension stand for V 1.0 ?

Will this change when V 2.0 is released?

If it does not stand for V 1.0, then why "1" ?

- Larry Weiss

20-Feb-09 07:51 PM

It does stand for 1.

But when they started work on version 2, they decided that instead of
having it install side-by-side with v1, they would try to make it
PowerShells installed to run .ps1 and .ps2 scripts, they would make all
ps v1 scripts work in ps v2...

Of course, there's a TON of features in v2 that don't work in v1, but
for some reason they abandoned the file extension as a way of
differentiating it, and chose to use a comment: #requires -version 2.0

If you ask me, considering how many language features and cmdlets are
not backwards compatible, it's a mistake -- they should use .ps2 and
just allow it to run .ps1 *also* -- but they've decided to save the
which might be language incompatible.
--
Joel

21-Feb-09 06:35 AM

as joel said the original idea was that version would be differentiated by
script extension.  That idea has not been implemented in v2.


To be honest it doesn't really matter how the versioning is achieved, as
long as there is a way to tell PowerShell that you need v1, v2, v3 or
whatever, and people rememebr to use it it will work
--
Richard Siddaway
All scripts are supplied "as is" and with no warranty
PowerShell MVP
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk

21-Feb-09 07:30 AM

Do you think that maybe they will drop the "1" eventually and just use ".PS" ?
For example .bat  .cmd  .vbs
Plus the number "1" is a particularly annoying character to use because it
renders visually similar to the letter "l".

I guess these early design decisions will haunt us forever.

- Larry

21-Feb-09 10:14 AM

See:
http://blogs.msdn.com/powershell/archive/2007/11/02/ctp-versioning.aspx

Marco

21-Feb-09 11:37 AM

I doubt that the 1 will be dropped anytime soon as it would be a huge
breaking change
--
Richard Siddaway
All scripts are supplied "as is" and with no warranty
PowerShell MVP
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk

21-Feb-09 12:13 PM

And it does collide then with the standard postscript extension.

--
Regards
Matthias

21-Feb-09 12:11 PM

Mmm other tools also have "scripting actions"

Automation tools
Network tracking tools
Data base tools
Debug tools

Notice none of the above tools can
be called a "scripting language"
or "follow the pattern of other MS
scripting language conventions"!

Remember powershell.exe is a tool,
in fact it is the Windows admin's
automation tool (where currently the
GUI
is one of it's most important parts).

So perhaps just enjoy automating
one's needed tools
within powershell.exe!

21-Feb-09 01:52 PM

Thanks so much for pointing me to Jeffrey Snover's comments on this.  It was
exactly the perspective I was curious about.  In that blog entry he describes
circumstances that may necessitate the need to change the extension to .PS2
But the change will be avoided if possible.

- Larry Weiss

21-Feb-09 03:07 PM

Wouldn't at all be a breaking change. They could make .ps1 be handled the
same way .ps is handled and just put the word out on the street to start
using .ps and it would eventually go away. Although I do still see .bat
files around even though .cmd has been the right extension for a while. But
anyway, the point is - they are at a point now where PowerShell 2.0 is going
to be the "Windows 3.1" release that really makes it the defacto standard.
They should fix it while they can. .ps1 is just dumb. .ps2 is a slippery
slope. What happens when you get to .ps10. etc...

Josh

21-Feb-09 06:18 PM

How would it be a breaking change?

- Larry

21-Feb-09 08:58 PM

Well, what's wrong with having .PS10? Hopefully by now we've all moved
past the whole 8.3 mindset, and aren't using any tools that have issues
with 4 character file extensions?

If they're not going to increment the numbers with every version, I'd
rather have .psh or .posh, over .ps1 -- but in principle I have no
problems with using .ps1 and .ps2 and .ps3 as long as they are consistent.

Personally I'd just as soon have them changed whenever the scripts in a
new version aren't guaranteed backwards compatible. Older,
forward-compatible versions' extensions could still be executable, and
the broken backwards compatability would be clear and obvious without
trying to run the script, or reading the source.
--
Joel "Jaykul" Bennett

21-Feb-09 10:30 PM

My argument against .ps10 has nothing to do with 8.3... it has to do with
using file extensions as metadata. That's what #requires is for and with
.psd1 its given us a nice clean way of declaring prerequisites.

Anyway, yeah having a file extension get versioned is crazy. But having one
that is supposed to have been versioned but decided against, that's even
crazier.

Josh

23-Feb-09 12:38 AM

What application a file works with isn't exactly metadata ... that's
what we use extensions for on Windows, after all ;) But of course, most
apps do what PowerShell has decided (belatedly) to do: open old files in
the new version fine (or convert them), and cause the old apps to throw
errors when you open a file for the new version.

IMO, the problem with that in a shell is that you can't use it to alter
the command-line completion.

So, if you have a "script.ps1" file in a folder which is in your
$ENV:PATH ... PowerShell 1 will execute it when you type "script" in the
console.  But it wouldn't do that if the file was named script.ps2 ...
and of course, a PowerShell 2 could look for ps2 AND ps1, but prefer ps2
the same as it prefers .ps1 to .exe.

So, if you use metadata instead of file extensions as a way to control
compatability, then two things happen (which are bad, in my opinion):

1) You have no way to have a v1 and a v2 version of a command which you
can put in a folder on your USB thumbdrive and add to the PATH whever
you go ... except to have something like "script.ps1" that calls either
you have any reason to have to ocassionally work on v1, you're going to
be tempted to keep all your scripts at v1.

2) Version 1 has to (attempt to) parse/execute v2 scripts to discover
they won't work, and thus show errors, instead of just ignoring them.

*shrug*

None of it is a big deal, one way or the other ... but for the scenarios
that I can think of, the extension seems better.
--
Joel

23-Feb-09 09:48 PM

Well PowerShell is already parsing the .ps1 files to present the parameters,
but either way... Extensions are kinda like domain names. If .ps3 for
example is two versions off from being widely used, there's plenty of time
for Sony to screw up the whole party by making some widely used .ps3
extension. I realized it was a pretty dumb move when I registered teo3.com,
teo4.com, teo5.com, etc and just gave them all up and registered
tabletoutlook.com instead.

But anyhow, it's all a moot point since they're sticking with .ps1 which of
course just makes the whole situation all the muddier. I find it humorous
that they rationalized their versioning decision based on the .NET CLR vs
Framework versioning scheme which is by all accounts a confusing mess.
Anyhow, my guess is we'll be using .ps1 forever. :)

Josh

28-Feb-09 06:58 PM

Just like the file extension for Visual Basic .NET, regardless of any
version, it ends with '.vbproj', '.vb'. As regardless of .NET
programming languages, the solution file ends with '.sln'.

FYI.

01-Mar-09 12:25 AM

There's a huge difference between a .vbproj and a .ps1, of course ...
project files are not commands, they're documents ... and ditto for .vb
files.

You could make the argument for .vbs and .js which are supported on
windows scripting host, but I don't think there's ever been a way to
declare a vbs non-backwards-compliant short of using their xml metadata
format ... and I'm pretty sure it's a non-issue only because you can't
SxS install them anyway.

As for the project files, they're also different because it's important
for most developers to be able to open old ones in the old tool and keep
them "old" instead of upgrading them, even when they're actually forward
compatible -- because they're *never* _backwards_ compatible.

Also, as a result, visual studio has to ship with a version selector,
and all those files are associated with the version selector which then
launches the appropriate version of visual studio (or newer) (if one is
available) after it peeks into the file ...

All of which is fine for documents, but not for commands you want to
type into a console ;)

Anyway. I get the feeling I'm beating a dead horse here, so I'll stop.
--
Joel

28-Feb-09 11:49 PM

Except that VB did not have the shortsightedness of naming their extension
.vb7... Would have looked kinda silly today.

20-Mar-09 12:44 PM

All of the preceding has been interesting, but to me misses a point.  I've always thought of the file extension as a sort of generic "type identifier".  The version specifier idea is new (to me) and (again to me) unwelcome.  Everbody else has lived with one ext thru multiple language versions, why not powershell?  There is a perfectly good version mechanism which Snover alludes to in the #comment notion -- which mechanism is also used in Unix shells :).  I would suggest that they back up a bit and perhaps just use ".psh" (leave .ps to postscript -- poor fellas me lads they aare).