What's the difference?
For example,
$t='notepad c:\temp\x.txt'
&$t # this fails
invoke-expression $t #this works
More generally, I'm still puzzled about when the interpretation of strings
occurs.
tia
What's the difference?
For example,
$t='notepad c:\temp\x.txt'
&$t # this fails
invoke-expression $t #this works
More generally, I'm still puzzled about when the interpretation of strings
occurs.
tia
Check out Keith's article, Effective PowerShell Item 10: Understanding PowerShell
Parsing Modes
http://keithhill.spaces.live.com/Blo...A97!6058.entry
-----
Shay Levi
$cript Fanatic
http://scriptolog.blogspot.com
Hebrew weblog: http://blogs.microsoft.co.il/blogs/scriptfanatic
> What's the difference?
>
> For example,
>
> $t='notepad c:\temp\x.txt'
> &$t # this fails
> invoke-expression $t #this works
> More generally, I'm still puzzled about when the interpretation of
> strings occurs.
>
> tia
>
"Shay Levi" <no@xxxxxx> wrote in message
news:8766a944fdd88ca000612134012@xxxxxxThanks. :-)
> Check out Keith's article, Effective PowerShell Item 10: Understanding
> PowerShell Parsing Modes
> http://keithhill.spaces.live.com/Blo...A97!6058.entry
In this case, the call operator (&) expects $t to be the *command* to
>> $t='notepad c:\temp\x.txt'
>> &$t # this fails
execute and not an entire command line (with args, etc). IOW, while
'notepad' is a valid command, 'notepad c:\temp\x.txt' isn't. This would
work:
$t = 'notepad'
&$t c:\temp\x.txt
Invoke-Expression executes the whole string as if it were type in at the
>> invoke-expression $t #this works
command line.
--
Keith
yep & runs a command, invoke-expression first parses a string of text,
and runs that, and thus is vulnerable to "powershell injection attacks".
if you specify a preparsed scriptblock you can run that with the &, and
unless your command is generated dynamically as a string, this is
preferable over invoke-expression..
$t={notepad c:\temp\x.txt}
&$t # this fails
or
$mypath = '.....something that works';
$t = {notepad $mypath}
&$t
Probably simpler to use scriptblocks (curly brackets) with &, rather than
strings, as Karl suggests. You don't have to be so concerned about what
constitutes a command, and what constitues an argument, which also leads to
simpler syntax eg with a string
& 'notepad' c:\temp\x.txt #An executable
& 'Get-Process' power* #A cmdlet
function sayhello {"hi there!"} ; & "sayhello" #A function
set-alias abc sayhello ; & "abc" #An alias
whereas with a scriptblock, you can just use
& {notepad c:\temp\x.txt } #Assuming the file exists
& {Get-Process power*}
etc
--
Jon
| Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Invoke-Expression Blues. | Kryten | PowerShell | 1 | 03 Nov 2008 |
| invoke-expression problem | Jacques | PowerShell | 2 | 06 Jun 2008 |
| Invoke-expression help for logparser | Vinod | PowerShell | 4 | 02 Aug 2007 |
| log output from invoke-expression | Frank | PowerShell | 4 | 03 Jul 2007 |
| Issue: Invoke-Expression with $args in the expression | =?Utf-8?B?Um9tYW4gS3V6bWlu?= | PowerShell | 1 | 22 Sep 2006 |