Vista - How can I ensure that a variable is a built-in powershell variable?

I have a question regarding variables.
Is there a way to ensure that retrieved variable such as *Preference
variables are indeed a built-in PowerShell variables?(they have "None"
as an option for all)

I was thinking about checking if a variable is of type
"System.Management.Automation.ActionPreference" but can anyone just
create a variable with *Preference as postfix and of type
"System.Management.Automation.ActionPreference"?

Any ideas?

- Sung

Sung M Kim wrote:
> I have a question regarding variables.
> Is there a way to ensure that retrieved variable such as *Preference
> variables are indeed a built-in PowerShell variables?(they have "None"
> as an option for all)
>
> I was thinking about checking if a variable is of type
> "System.Management.Automation.ActionPreference" but can anyone just
> create a variable with *Preference as postfix and of type
> "System.Management.Automation.ActionPreference"?

Sure, anybody can, but why not let them?

Adam Milazzo wrote:
> Sung M Kim wrote:
> > I have a question regarding variables.
> > Is there a way to ensure that retrieved variable such as *Preference
> > variables are indeed a built-in PowerShell variables?(they have "None"
> > as an option for all)
> >
> > I was thinking about checking if a variable is of type
> > "System.Management.Automation.ActionPreference" but can anyone just
> > create a variable with *Preference as postfix and of type
> > "System.Management.Automation.ActionPreference"?
>
> Sure, anybody can, but why not let them?

I was simply trying to retrieve variables that affect PowerShell's
behavior, not the ones that do nothing to how PowerShell works...
And I just wanted to know if there is a way or a flag to check against
for built-in variables

with the release of powershell (whatever version), there is always
going to be a set of variables are part of powershell, and this is only
goiung to be a handful, so i think a function with them hard coded
would suffice..

however a question and a presumption: i presume that a powershell
variable is there 1) regardless of the host, and is there for the
entire lifespan of the shell?

Karl

klumsy@xtra.co.nz wrote:
> however a question and a presumption: i presume that a powershell
> variable is there 1) regardless of the host, and is there for the
> entire lifespan of the shell?

No, they could be removed by the user or the host at any time...

i didn't know they could be removed.. still if they are static , a
defined list, you could make a function that has t hem hard coded, and
checks for their existence.

Adam Milazzo wrote:
> klumsy@xtra.co.nz wrote:
> > however a question and a presumption: i presume that a powershell
> > variable is there 1) regardless of the host, and is there for the
> > entire lifespan of the shell?
>
> No, they could be removed by the user or the host at any time...

The only way currently to find an exhaustive list is the documentation:
"get-help about_automatic_variables." Other than that, we do not currently
attach any metadata to them.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Sung M Kim" <DontBotherMeWithSpam@gmail.com> wrote in message
news:1158753822.808445.112870@b28g2000cwb.googlegroups.com...
> Adam Milazzo wrote:
>> Sung M Kim wrote:
>> > I have a question regarding variables.
>> > Is there a way to ensure that retrieved variable such as *Preference
>> > variables are indeed a built-in PowerShell variables?(they have "None"
>> > as an option for all)
>> >
>> > I was thinking about checking if a variable is of type
>> > "System.Management.Automation.ActionPreference" but can anyone just
>> > create a variable with *Preference as postfix and of type
>> > "System.Management.Automation.ActionPreference"?
>>
>> Sure, anybody can, but why not let them?
>
> I was simply trying to retrieve variables that affect PowerShell's
> behavior, not the ones that do nothing to how PowerShell works...
> And I just wanted to know if there is a way or a flag to check against
> for built-in variables
>

Lee Holmes [MSFT] wrote:
> The only way currently to find an exhaustive list is the documentation:
> "get-help about_automatic_variables." Other than that, we do not currently
> attach any metadata to them.

Thank you for the response.
Yes, Metadata for variable was what I was looking for basically...
I guess I am going to have to deal with this for the current drop