Controlling the Scope of Variables

re: Controlling the Scope of Variables

netvance — Sat, 14 Apr 2007 23:55:50 GMT

Maybe we should start our powershell software development a bit easier :) The Private statement in VBScript is concerned with classes; we’re going to take the liberty of extending the definition of Private here, primarily because we aren’t going to talk about classes. Instead of talking about private variables in terms of classes, we’re going to talk about private variables in terms of scope.

In Windows PowerShell all you have to do is set the scope to Private. For example, this command creates a variable named $a with the scope set to private. Note that, when specifying a scope, you do not preface the variable name with a $; however, in your commands you will still refer to this variable as $a.

Here’s the command:

$Private:a = 5

Because this is a private variable it will be available only in the scope in which it was created. If you type $a from the command prompt you’ll get back the value of $a. However, if you run a script that simply echoes back the value of $a you won’t get back anything; that’s because, as a private variable, $a is not available outside the command shell scope.

re: PS blogger

james beard — Sun, 15 Apr 2007 00:16:30 GMT

Dear PS,

Do you have an email address?

Interesting Finds: April 15, 2007

Jason Haley — Sun, 15 Apr 2007 17:44:46 GMT

re: Controlling the Scope of Variables

Clift Norris — Thu, 19 Apr 2007 18:50:56 GMT

First let me say that PowerShell has REALLY helped me and my company.

We have used the tool to do some very interesting things!

Kudos to the entire PSH development team.

But the scoping rules described above are 'unexpected'.

>"This is soooo powerful."

Yes, it is powerful, but it is also error-prone. Along with

"GOTO considered harmful" we have over the years learned that

global variables are harmful if not used carefully and sparingly.

Being able to control the scope of variables and avoid unintended

access to variables is something that experienced programmers

have come to rely upon.

It could be that my concern is due to my use of PowerShell in a

manner that is not entirely as the authors intended.

I'm using it as a scripting language (on steroids!) and not so

much as a "shell". Used as a shell, the above scoping concepts

are surely powerful and helpful. But when my scripts get to be

a couple hundred lines of code, I begin to have reservations

about the PowerShell scoping rules.

Yes, the scoping rules allow some very clever tasks to be accomplished.

I suppose 'with power comes responsibility' and we just need

to be diligent in our use of scoping prefixes ($global:foo).

Fun with Paths

Windows PowerShell — Sat, 28 Apr 2007 00:21:53 GMT

Jeffrey wrote a great post for wizards about the scope of variables in PowerShell, so to maintain balance,

Line Count with PowerShell

code-o-rama — Tue, 23 Oct 2007 07:18:43 GMT

Starting to get the hang of PowerShell. Today I wanted to quickly count the number of lines in some source

re: Controlling the Scope of Variables

Tim Johnson — Tue, 24 Jun 2008 06:33:34 GMT

First off, excellent article. It's exactly the answer to what I was wondering about scoping in PowerShell.

Clift, if you're still following this, what is your concern, specifically? All variables are local in scope by default, so it's not like all variables are being made global, and anyone who is familiar with a scripting language should be familiar with the concept of having variables inherit down the scope. I don't think anyone will be accidentally setting up-scoped variables, given the default syntax, so am I missing something (entirely possible)?

re: Controlling the Scope of Variables

Doug Clutter — Fri, 12 Jun 2009 19:33:20 GMT

Have only been working with PowerShell a short, short time, but I've found it incredibly useful.

How can we control the scope of functions? For instance, lets say I have this file:

SomeUsefulFunction.ps1

--------------

function SomeUsefulFunction { ... }

Now, I want to use the function, so I try this:

PS> ./SomeUsefulFunction.ps1

PS> SomeUsefulFunction "parm1"

The term 'SomeUsefulFunction' is not recognized...

Taking a cue from this post, I tried this:

function 1:SomeUsefulFunction { ... }

...but that didn't work.

Perhaps, it would be best to address the underlying issue? What are some of the "best practices" to organizing PS code? Should we even be writing functions, or should we structure things like this:

SomeUsefulFunction.ps1

--------------

params ( ... )

process { ... }

end { ... }

PS> ./SomeUsefulFunction.ps1 "parm1"