Will this change when V 2.0 is released?
If it doesn't stand for V 1.0, then why "1" ?
- Larry Weiss
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
"compatible" with 1. So instead of requiring you to have both
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
"breaking" of changing file extensions for a hypothetical future version
which might be language incompatible.
--
Joel
#requires actually exists in v1
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
Do you think that maybe they will drop the "1" eventually and just use ".PS" ?
".PS1" doesn't follow the pattern of other MS scripting language conventions.
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
See:
http://blogs.msdn.com/powershell/archive/2007/11/02/ctp-versioning.aspx
Marco
And it does collide then with the standard postscript extension.
--
Regards
Matthias
>
> ".PS1" doesn't follow the pattern
> of other MS scripting language
>
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!
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
Josh
"RichS [MVP]" <Rich...@discussions.microsoft.com> wrote in message
news:50E75371-2F01-438C...@microsoft.com...
- Larry
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
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
"Joel Bennett" <Jay...@HuddledMasses.org> wrote in message
news:eTybtEJl...@TK2MSFTNGP04.phx.gbl...
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
"script-v1.ps1" or "script-v2.ps1" depending on the situation -- so if
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
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
"Joel Bennett" <Jay...@HuddledMasses.org> wrote in message
news:#D5ULkXl...@TK2MSFTNGP05.phx.gbl...
FYI.
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
"bluefin" <desertca...@gmail.com> wrote in message
news:5ac5d2a3-85fd-4ed1...@u18g2000pro.googlegroups.com...