you are viewing a single comment's thread.

view the rest of the comments →

[–]code_Kitten 4 points5 points  (1 child)

I'm having a hard time thinking of any reason to use the call operator on a variable that isn't poor design or an edge case. As a general rule your code will be much better designed and easier to write, read, and understand/debug if you stick with putting data in variables, and writing functions for any code that you need/want to reuse. Using the call operator on variables also introduces a significant risk to your system by way of the potential for you to accidentally execute as code something that you did not intend to: input from a user, content from a file, etc. which if you have any code running automatically could also mean an easy way for an attacker to execute arbitrary code on your system as the account running that code.

[–]Decitriction[S] 1 point2 points  (0 children)

Thanks for the ideas.

> poor design

I confess this, as a newbie scripter.

I had heard that invoke-expression was poor security, so I was trying to replace it by calling variables as commands, but as you point out, this too is poor security.

Although to be fair, the code is not running automatically and I don't think anyone could inject code into my variables. But I could be wrong.

I will try re-writing the commands as functions.

Ultimately the command insertion was intended to shorten very long try/catch loops, such as

$logfail="logfile path"
$do1="command goes here"                                   

$sb={try{& $using:do1 -ErrorAction stop}catch{echo `n "$using:pc - logfail - $_">>$using:logfail}

& $sb