I understand that this command is wrong and I understand how to make it
right. What i don't understand is the error message. What's going on
under the hood producing this error message:
PS F:\> invoke-expression { gps }
Invoke-Expression : A parameter cannot be found that matches parameter
name 'gps '.
At line:1 char:18
+ invoke-expression <<<< { gps }



Any ideas?

Why on earth gps is considered to be a paramter name in the message it's
not prefixed by '-' sign or something.
From help:
To provide a script block as the value of the Command parameter, you
must include it within quotation marks. Otherwise, the shell will
recognize the script block and evaluate it rather than pass it in a
literal form as the value of the Command parameter.

So I would imagine that the parser would recognize { gps } as a
scriptblock and process it. Of course the scriptblock parameter would
make no sense for invoke-expression at which stage it will happily bug
out, but what happens in reality is something different and I would like
to know what.

One guess would be that 'gps ', that is displayed is exactly { gps
}.tostring(), so the parser tries to cast the parameter to a string,
which is only natural. But why it is refering to it as to parameter
*name*, where it's obvious that in fact's it's *value*.

Just to re-iterate, I don't really need to hear how to write this
statement so it works, I know this. The question is, why this statement
gives this particular error message and how exactly command line parsing
is processed. Also I'd like to mention that I've thoroughly read
about_parsing. There is a vague paragraph there saying:

Get-Command "-type" cmdlet

PowerShell will attempt to use the "-type" value as an argument to the
first positional parameter, while the "cmdlet" argument will be treated
as a parameter name, causing the command to fail.

Why cmdlet will be treated as a parameter name is beyond me. it doesn't
have hyphen.

I will let the Dev guys give you a detailed answer, but the short answer is
that you dont have to have '-'. Most if not all cmdlets will gladly process
parameters without the - although without the '-' it has to be placement
sensative. I know this is not a cmdlet, but the same applies

function foo {
param($say,$hello)
$say
$hello
}

Now... I can call that a couple of ways
foo Hi there
or
foo -say Hi -hello There

From my understanding when you pass a parameter using {} it is seen as an
array.
So when you do:
invoke-expression {gps}
you are passing an array to invoke-expression... which it apparently doesn't
take kindly to.

Again.... just my take on it.

--
Brandon Shell
---------------
Stop by my blog some time
http://www.bsonposh.com/
Try the "Search of Powershell Blogs"
--------------------------------------
"Andrew Savinykh" <andrewsav@gmail.com> wrote in message
news:OqwKUzbRHHA.4632@TK2MSFTNGP04.phx.gbl...
>I understand that this command is wrong and I understand how to make it
>right. What i don't understand is the error message. What's going on under
>the hood producing this error message:
> PS F:\> invoke-expression { gps }
> Invoke-Expression : A parameter cannot be found that matches parameter
> name 'gps '.
> At line:1 char:18
> + invoke-expression <<<< { gps }
>
> Any ideas?
>
> Why on earth gps is considered to be a paramter name in the message it's
> not prefixed by '-' sign or something.
> From help:
> To provide a script block as the value of the Command parameter, you must
> include it within quotation marks. Otherwise, the shell will recognize the
> script block and evaluate it rather than pass it in a literal form as the
> value of the Command parameter.
>
> So I would imagine that the parser would recognize { gps } as a
> scriptblock and process it. Of course the scriptblock parameter would make
> no sense for invoke-expression at which stage it will happily bug out, but
> what happens in reality is something different and I would like to know
> what.
>
> One guess would be that 'gps ', that is displayed is exactly {
> gps }.tostring(), so the parser tries to cast the parameter to a string,
> which is only natural. But why it is refering to it as to parameter
> *name*, where it's obvious that in fact's it's *value*.
>
> Just to re-iterate, I don't really need to hear how to write this
> statement so it works, I know this. The question is, why this statement
> gives this particular error message and how exactly command line parsing
> is processed. Also I'd like to mention that I've thoroughly read
> about_parsing. There is a vague paragraph there saying:
>
> Get-Command "-type" cmdlet
>
> PowerShell will attempt to use the "-type" value as an argument to the
> first positional parameter, while the "cmdlet" argument will be treated as
> a parameter name, causing the command to fail.
>
> Why cmdlet will be treated as a parameter name is beyond me. it doesn't
> have hyphen.

Invoke-Expression takes a string not a SCRIPTBLOCK.

Invoke-Expression "gps"
--
Jeffrey Snover [MSFT]
Windows PowerShell Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, no confers rights.
Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx

I know. This was not the question. But thank you anyway.

Jeffrey Snover [MSFT] wrote:
> Invoke-Expression takes a string not a SCRIPTBLOCK.
>
> Invoke-Expression "gps"

Brandon Shell wrote:
> I will let the Dev guys give you a detailed answer, but the short answer
> is that you dont have to have '-'. Most if not all cmdlets will gladly
> process parameters without the - although without the '-' it has to be
> placement sensative. I know this is not a cmdlet, but the same applies
>
> function foo {
> param($say,$hello)
> $say
> $hello
> }
>
> Now... I can call that a couple of ways
> foo Hi there
> or
> foo -say Hi -hello There
>

This is all true, but this doesn't explain why the error message says
that gps is a parameter *name* as I stressed out in the original post.
All this positional parameters are nice and good, but if you don't
specify hyphen it is always *value* unless you can show me the case when
it's not. In your case (although it's a function and not a cmdlet, but
let's assume it dosn't matter here)Hi and There are values and say and
hello are names.


> From my understanding when you pass a parameter using {} it is seen as
> an array.
> So when you do:
> invoke-expression {gps}
> you are passing an array to invoke-expression... which it apparently
> doesn't take kindly to.

It's a script block and not an array, which is easy to find out by
callyn get-member on it. And yes, as I stated in the original post it's
not at all surprising that invoke-expression doesn't work with a script
block when in fact it expects a string. So the question still stands.

>
> Again.... just my take on it.
>

Thank you!

Invoke-Expression expects a string as its input. Using Invoke-Expression
{gps} you are not supplying a string therefore it won't treat your input as
valid. It seems to me that it is then attempting to find a paramter called
gps and failing which is why you get the error message.

I have seen similar messages before.
--
Richard Siddaway

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


"Andrew Savinykh" wrote:

> I know. This was not the question. But thank you anyway.
>
> Jeffrey Snover [MSFT] wrote:
> > Invoke-Expression takes a string not a SCRIPTBLOCK.
> >
> > Invoke-Expression "gps"
>

Yep, that's what I thought too, now I'd like to know why. I'd like to
know how the parser works in this respect. Thank you for the reply!

RichS wrote:
> Invoke-Expression expects a string as its input. Using Invoke-Expression
> {gps} you are not supplying a string therefore it won't treat your input as
> valid. It seems to me that it is then attempting to find a paramter called
> gps and failing which is why you get the error message.
>
> I have seen similar messages before.

On Feb 1, 1:23 am, Andrew Savinykh <andrew...@gmail.com> wrote:
> Yep, that's what I thought too, now I'd like to know why. I'd like to
> know how the parser works in this respect. Thank you for the reply!
>


if you just want to run a scriptblock itself you can do this

$a = {Get-Process }

&$a

or just simply

&{ get-Process}

a scriptblock is a specific aspect of the language, rich and declared
inside the scripts text itself.. it isn't excaped or anything..
however invoke-expression takes in a string, not a scriptblock.. most
dynamic languages have this sort of thing, most call it EVAL() or
something like that. the text doesn't have to come from the code/
script itself. its a string, you could have put together this string
from a formula, user input, an external file, or whatnot.. but
basically invoke-expression, will take that string, parse it, turn it
into a scriptblock, then execute it.. really eval etc are in many
languages, its just another layed of abraction.. in sql it would be
the equivilant of dynamic sql.. sometimes you just have to
dfynamically sculpt the sql in a string, then run it. and in doing so
you gotta take care of escaping quotes etc etc, so that the string
within your outer quotes is valid.

scriptblocks are different beyond that, they are strongly typed
funtional language like first class citizens, "semi-compiled"

i.e do something invalid like this

$a = { 1.0/2.1/3@1 }

and you get an error then, even though have haven't run the
scriptblock at thyat stage.. however its not a valid scriptblock..
however if you were doing this in a string

$a = '1.0/2.1/3@1' that is a valid string.. its not until you invoke-
expression it that you'll discover the problems..
invoke-expression $a

Hope this is the answer you were looking for.

and if you want to go deeper with scriptblocks.. play with these and
get your mind around them.. in a way scriptblocks are very much like
anonymous methods in C#, with an optional parameter definition...

functions, despite the syntax are indeed just scriptblocks... this
will show it

dir function: | % { $_.scriptblock}

have alook at the results above, they are quite interesting..
functions are basically scriptblocks stored in a common provider with
some extra metadata.

you can declare parameterized scriptblocks outside the context of
functions (much like anonymous methods in C#)

$a = {param([string]$ratdog) "hello $ratdog" }

that there declared a scriptblock that takes a string parameter.. so
to call it i could run

&$a something

or specify the parameter by name

&$a -ratdog "something else"

however i don't even need to store teh scriptblock in a variable, but
i could call it directly and pass in the parameters

&{param([string]$ratdog) "hello $ratdog" } "another test"

if this stuff confused you, (if did me at first too), play around in
powershell, experimenting until it clicks, and when it does, you'll
get a great big smile on your face.

I think I got the question, but I don't have them ;-)

Get-Command -CommandType Script

Get-Command -CommandType ExternalScript
(all scripts in path)

PoSH> Get-Command -CommandType foo
Get-Command : Cannot bind parameter 'CommandType'. Cannot convert value
"foo" to type "System.Management.Automat
mandTypes" due to invalid enumeration values. Specify one of the following
enumeration values and try again. The
le enumeration values are "Alias, Function, Filter, Cmdlet, ExternalScript,
Application, Script, All".
At line:1 char:25
+ Get-Command -CommandType <<<< foo

greetings /\/\o\/\/

<klumsy@xtra.co.nz> wrote in message
news:1170365225.423155.210630@a34g2000cwb.googlegroups.com...
> On Feb 1, 1:23 am, Andrew Savinykh <andrew...@gmail.com> wrote:
>> Yep, that's what I thought too, now I'd like to know why. I'd like to
>> know how the parser works in this respect. Thank you for the reply!
>>
>
>
> if you just want to run a scriptblock itself you can do this
>
> $a = {Get-Process }
>
> &$a
>
> or just simply
>
> &{ get-Process}
>
> a scriptblock is a specific aspect of the language, rich and declared
> inside the scripts text itself.. it isn't excaped or anything..
> however invoke-expression takes in a string, not a scriptblock.. most
> dynamic languages have this sort of thing, most call it EVAL() or
> something like that. the text doesn't have to come from the code/
> script itself. its a string, you could have put together this string
> from a formula, user input, an external file, or whatnot.. but
> basically invoke-expression, will take that string, parse it, turn it
> into a scriptblock, then execute it.. really eval etc are in many
> languages, its just another layed of abraction.. in sql it would be
> the equivilant of dynamic sql.. sometimes you just have to
> dfynamically sculpt the sql in a string, then run it. and in doing so
> you gotta take care of escaping quotes etc etc, so that the string
> within your outer quotes is valid.
>
> scriptblocks are different beyond that, they are strongly typed
> funtional language like first class citizens, "semi-compiled"
>
> i.e do something invalid like this
>
> $a = { 1.0/2.1/3@1 }
>
> and you get an error then, even though have haven't run the
> scriptblock at thyat stage.. however its not a valid scriptblock..
> however if you were doing this in a string
>
> $a = '1.0/2.1/3@1' that is a valid string.. its not until you invoke-
> expression it that you'll discover the problems..
> invoke-expression $a
>
> Hope this is the answer you were looking for.
>
>