Vista - Bug in parsing or processing of a function definition?

Can others reproduce what seems to be a bug in the parsing or
processing of a function definition?

PS C:\PowerShellScripts> function global:script: {write-host "From a
globally scoped script"}
PS C:\PowerShellScripts> script:
The term 'script:' is not recognized as a cmdlet, function, operable
program, or script file. Verify the term and try a
gain.
At line:1 char:7
+ script: <<<<

Superficially there seems to be no function named "script:" but it
exists as you can demonstrate using the following command (easier to
read on screen in PowerShell):

PS C:\PowerShellScripts> dir function:sc*

CommandType Name Definition
----------- ---- ----------
Function script: write-host "From a globally scoped script"

And it executes if you use the following command:

PS C:\PowerShellScripts> global:script:
From a globally scoped script
PS C:\PowerShellScripts>

But it seems to be specific to the name "script:". See the following:

PS C:\PowerShellScripts> function global:something: {write-host "From
a globally scoped script"}
PS C:\PowerShellScripts> something:
From a globally scoped script
PS C:\PowerShellScripts> global:something:
From a globally scoped script
PS C:\PowerShellScripts>

If the "name" of the function "global:script:" is recognized as
"script:" surely it should be possible to execute the script using its
name.

Looks like a bug to me. Can others reproduce?

Thanks

Andrew Watt MVP

Yes it is reproducible & I think its related to the fact that there is a
script scope takes precedence & that is where PowerShell is looking for the
function
--
Richard Siddaway

Please note that all scripts are supplied "as is" and with no warranty


"Andrew Watt [MVP]" wrote:

> Can others reproduce what seems to be a bug in the parsing or
> processing of a function definition?
>
> PS C:\PowerShellScripts> function global:script: {write-host "From a
> globally scoped script"}
> PS C:\PowerShellScripts> script:
> The term 'script:' is not recognized as a cmdlet, function, operable
> program, or script file. Verify the term and try a
> gain.
> At line:1 char:7
> + script: <<<<
>
> Superficially there seems to be no function named "script:" but it
> exists as you can demonstrate using the following command (easier to
> read on screen in PowerShell):
>
> PS C:\PowerShellScripts> dir function:sc*
>
> CommandType Name Definition
> ----------- ---- ----------
> Function script: write-host "From a globally scoped script"
>
> And it executes if you use the following command:
>
> PS C:\PowerShellScripts> global:script:
> From a globally scoped script
> PS C:\PowerShellScripts>
>
> But it seems to be specific to the name "script:". See the following:
>
> PS C:\PowerShellScripts> function global:something: {write-host "From
> a globally scoped script"}
> PS C:\PowerShellScripts> something:
> From a globally scoped script
> PS C:\PowerShellScripts> global:something:
> From a globally scoped script
> PS C:\PowerShellScripts>
>
> If the "name" of the function "global:script:" is recognized as
> "script:" surely it should be possible to execute the script using its
> name.
>
> Looks like a bug to me. Can others reproduce?
>
> Thanks
>
> Andrew Watt MVP
>

The problem stems from using a colon ( : ) in the name of the function.
Powershell uses paths to everything -- functions are referenced by
paths, variables are referenced by paths etc etc. These paths use
colons as delimiters and if you start naming things with embedded
colons, you're asking for trouble. Ideally, powershell should not allow
leaf or container nodes in a path to be named with a colon in them for
any provider, but I guess they never came up with a satisfying solution
for that one. They cannot be escaped even with the backtick... the best
you can do is to remove ambuigity in the path by fully qualifying it:

PS > function global:script: { write-host "hello, world." }

PS > gc Function::global:script:
write-host "hello, world."

While I can retrieve the body, I haven't been able to execute it
either... :-|

- Oisin

Andrew Watt [MVP] wrote:
> Can others reproduce what seems to be a bug in the parsing or
> processing of a function definition?
>
> PS C:\PowerShellScripts> function global:script: {write-host "From a
> globally scoped script"}
> PS C:\PowerShellScripts> script:
> The term 'script:' is not recognized as a cmdlet, function, operable
> program, or script file. Verify the term and try a
> gain.
> At line:1 char:7
> + script: <<<<
>
> Superficially there seems to be no function named "script:" but it
> exists as you can demonstrate using the following command (easier to
> read on screen in PowerShell):
>
> PS C:\PowerShellScripts> dir function:sc*
>
> CommandType Name Definition
> ----------- ---- ----------
> Function script: write-host "From a globally scoped script"
>
> And it executes if you use the following command:
>
> PS C:\PowerShellScripts> global:script:
> From a globally scoped script
> PS C:\PowerShellScripts>
>
> But it seems to be specific to the name "script:". See the following:
>
> PS C:\PowerShellScripts> function global:something: {write-host "From
> a globally scoped script"}
> PS C:\PowerShellScripts> something:
> From a globally scoped script
> PS C:\PowerShellScripts> global:something:
> From a globally scoped script
> PS C:\PowerShellScripts>
>
> If the "name" of the function "global:script:" is recognized as
> "script:" surely it should be possible to execute the script using its
> name.
>
> Looks like a bug to me. Can others reproduce?
>
> Thanks
>
> Andrew Watt MVP

belay the previous gibber!

I can execute it; simply:

PS >global:script:
hello, world.

And just to add, yes, RichS is right -- powershell will parse "script:"
as a namespace qualifier before a function name. There is a precedence
to this - it's listed online somewhere.

- Oisin

Oisin Grehan wrote:
> The problem stems from using a colon ( : ) in the name of the function.
> Powershell uses paths to everything -- functions are referenced by
> paths, variables are referenced by paths etc etc. These paths use
> colons as delimiters and if you start naming things with embedded
> colons, you're asking for trouble. Ideally, powershell should not allow
> leaf or container nodes in a path to be named with a colon in them for
> any provider, but I guess they never came up with a satisfying solution
> for that one. They cannot be escaped even with the backtick... the best
> you can do is to remove ambuigity in the path by fully qualifying it:
>
> PS > function global:script: { write-host "hello, world." }
>
> PS > gc Function::global:script:
> write-host "hello, world."
>
> While I can retrieve the body, I haven't been able to execute it
> either... :-|
>
> - Oisin
>
> Andrew Watt [MVP] wrote:
> > Can others reproduce what seems to be a bug in the parsing or
> > processing of a function definition?
> >
> > PS C:\PowerShellScripts> function global:script: {write-host "From a
> > globally scoped script"}
> > PS C:\PowerShellScripts> script:
> > The term 'script:' is not recognized as a cmdlet, function, operable
> > program, or script file. Verify the term and try a
> > gain.
> > At line:1 char:7
> > + script: <<<<
> >
> > Superficially there seems to be no function named "script:" but it
> > exists as you can demonstrate using the following command (easier to
> > read on screen in PowerShell):
> >
> > PS C:\PowerShellScripts> dir function:sc*
> >
> > CommandType Name Definition
> > ----------- ---- ----------
> > Function script: write-host "From a globally scoped script"
> >
> > And it executes if you use the following command:
> >
> > PS C:\PowerShellScripts> global:script:
> > From a globally scoped script
> > PS C:\PowerShellScripts>
> >
> > But it seems to be specific to the name "script:". See the following:
> >
> > PS C:\PowerShellScripts> function global:something: {write-host "From
> > a globally scoped script"}
> > PS C:\PowerShellScripts> something:
> > From a globally scoped script
> > PS C:\PowerShellScripts> global:something:
> > From a globally scoped script
> > PS C:\PowerShellScripts>
> >
> > If the "name" of the function "global:script:" is recognized as
> > "script:" surely it should be possible to execute the script using its
> > name.
> >
> > Looks like a bug to me. Can others reproduce?
> >
> > Thanks
> >
> > Andrew Watt MVP