Re: [MSH] WMI Help
- From: "Jeff Jones [MSFT]" <jeffjon@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 7 Nov 2005 08:54:12 -0800
You mention that you thought about using $global:$class for clarity. I
would caution you against doing that. This means that you will always
access the variable in the global scope whether or not the script is
dot-sourced. Instead, consider using $script:$class. If the script is
dot-sourced into the global scope then $script:class is equivalent to
$global:class. If the script is not dot-sourced then you aren't poluting
the global scope at all but the variable would be available to the entire
script.
--
Jeff Jones [MSFT]
Microsoft Command Shell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"/\/\o\/\/" <no@xxxxxxxx> wrote in message
news:eMQfL5e4FHA.2676@xxxxxxxxxxxxxxxxxxxxxxx
> Jeffrey Snover [MSFT] wrote:
>> Impressive stuff!
>> BTW - when you dot source the file, all side effects occur in the current
>> scope. What that means is that in addition to $classes being defined so
>> was $MS, $OPT, $MC and all the other "worker" variables that you used.
>> You can avoid this by moving the line
>> $classes = @{}
>> to the top and then putting the rest of the logic in a
>> &{
>> }
>> construct. This says, "Execute this script block in a new scope". All
>> the worker variables are created in a worker scope which gets discarded
>> at the end of the script block. This script block will not have $classes
>> defined so it will search the stack and find it in the parent scope and
>> will bind to it. If you tried to WRITE to $classes - it would make a
>> copy in the local scope and then throw that away as well but because you
>> are using methods $classes.Add(), you are modifing the contents of the
>> parent variable.
>>
>> This is a useful technique for keeping your environment tidy.
>>
> thx,
>
> I was thinking about returning it or use $global:$class (for Clearity),
>
> as I working on this from a WMI explorer I wrote in .NET a couple Years
> ago, I think it part by part and putting it together at the end.
> (that why for example the "Emty" managementScope is there (for later
> switch to another namesspace)
>
> Wat would be Nice, as Keith already mentioned,
> was using Match-string like this :
>
> $classes | match-String "win32_.*"
> or even
> $classes | fl | match-String "win32_.*"
>
> (In tryed overruling the ToString, as in a Tip of Bruce,
> but that did not work also.)
>
> Second thing I did not like was :
>
> $_.get_Qualifiers()["description"].value
>
> I would want to be able to do is this :
>
> $_.Qualifiers.description.value
>
> (as it was in .NET)
>
> gr /\/\o\/\/
.
- Follow-Ups:
- Re: [MSH] WMI Help
- From: /\\/\\o\\/\\/
- Re: [MSH] WMI Help
- References:
- [MSH] WMI Help
- From: Keith Hill
- Re: [MSH] WMI Help
- From: James Truher [MSFT]
- Re: [MSH] WMI Help
- From: /\\/\\o\\/\\/
- Re: [MSH] WMI Help
- From: /\\/\\o\\/\\/
- Re: [MSH] WMI Help
- From: Jeffrey Snover [MSFT]
- Re: [MSH] WMI Help
- From: /\\/\\o\\/\\/
- [MSH] WMI Help
- Prev by Date: Re: [MSH] tee-object is almost useless without an -Append option
- Next by Date: Re: [MSH] Bug with using enumerations
- Previous by thread: Re: [MSH] WMI Help
- Next by thread: Re: [MSH] WMI Help
- Index(es):
Relevant Pages
|