Access upstream pipeline objects

I was trying to get a list of all parameter names, types and the cmdlet name they're associated with. I can get this information with this command:

161# gcm -type cmdlet |
select @{e={$_.Name};n="CmdletName"} -expand ParameterSets |
select CmdletName -expand Parameters |
Sort Name -uniq | ft Name,CmdletName,ParameterType

However my initial approach didn't quite work because I needed access to one of the upstream objects (CmdletInfo) to grab the Cmdlet name for each parameter and there wasn't an obvious way to do that:

149# gcm -type cmdlet | %{$_.ParameterSets} | %{$_.Parameters} |
sort Name -Unique | select Name,ParameterType

What I really wanted to do was something like this:

162# gcm -type cmdlet | %{$_.ParameterSets} | %{$_.Parameters} |
sort Name -Unique | select Name,$pipe[-3].Name,ParameterType

Of course this syntax doesn't work because there isn't a $pipe object but the idea is to be able to access $_ at any previous stage of the pipline. There are quite a few case would this would be handy. So instead of trying to create custom objects and add stuff to them all the way down the pipeline, you could pull together the pieces at the end (say for an Format-Table command).

BTW I also tried and kind of expected this to work but it doesn't:

164# gcm -type cmdlet | %{$_.ParameterSets;$global:cmdletName=$_.Name} |
%{$_.Parameters} | sort Name |
ft Name,@{e={$global:cmdletName}},ParameterType

My guess is that it has to do with when the Format-Table hashtable formatter expression $global:cmdletName gets evaluated. So I tried this and it doesn't work either:

168# gcm -type cmdlet | %{$_.ParameterSets;$global:cmdletName=$_.Name} |
%{$_.Parameters} | sort Name -uniq |
ft Name,@{e={invoke-string "$global:cmdletName"};l="CmdletName"},
ParameterType

--
Keith

Hi Keith Hill

> 164# gcm -type cmdlet | %{$_.ParameterSets;$global:cmdletName=$_.Name} |
> %{$_.Parameters} | sort Name |
> ft Name,@{e={$global:cmdletName}},ParameterType
>
> My guess is that it has to do with when the Format-Table hashtable
> formatter expression $global:cmdletName gets evaluated.

This does not work as sort-object fetches _all_ objects before passing
them (sorted) back to the pipe. Hence ft is actually called only once
and your cmdletName variable seems as it doesn't change. Next (I guess)
you should update cmdletName before placing $_.ParameterSets into the pipe:

gcm -type cmdlet | %{$global:cmdletName=$_.Name;$_.ParameterSets} |
%{$_.Parameters} |
ft Name,@{e={$global:cmdletName}},ParameterType

cu

max

"Maximilian Hänel" <ngSpam@smjh.de> wrote in message
news:OfJtHofBHHA.3380@TK2MSFTNGP04.phx.gbl...
> This does not work as sort-object fetches _all_ objects before passing
> them (sorted) back to the pipe. Hence ft is actually called only once and
> your cmdletName variable seems as it doesn't change. Next (I guess) you
> should update cmdletName before placing $_.ParameterSets into the pipe:

Yeah that must be why globals are evil. :-) Actually the following does
work:

161# gcm -type cmdlet |
select @{e={$_.Name};n="CmdletName"} -expand ParameterSets |
select CmdletName -expand Parameters |
Sort Name -uniq | ft Name,CmdletName,ParameterType

I just wanted to bring up the issue of gaining access to previous objects in
the pipeline. However what you point out is why that just won't work.
Certain cmdlets like sort-object accumulate all objects before shuffling
(well sorting) them and sending them on down the pipe. So strike that idea.
That just leaves creating custom objects (PSCustomObject) using
select-object and adding synthetic properties to objects via add-member.

--
Keith

I just wanted to bring up the issue of gaining access to previous
objects in
the pipeline.

that is still a valid goal, because 8 times out of 10, your pipeline
mightn't rearrange things and there is a direct relationship to a
parent.. often a one to one, or sometimes a one to many.. i.e

dir *.txt | gc | something

well at something you are dealing with a one to many (one file, has
many lines of text) , but something just sees a stream of lines of
text, and the relationship to the file that it came from is lost.. so
its definately a valid scenario and issue. I have thought about it hard
and long , and when i have time, i plan a bunch of cmdlets to help aide
this needed scenario..

Karl

This is a pretty common scenario. Usually I deal with it in one of two
ways:

1. Use select or add-member to attach references to the parent. This is
basically what Keith did here.

>161# gcm -type cmdlet |
> select @{e={$_.Name};n="CmdletName"} -expand ParameterSets |
> select CmdletName -expand Parameters |
> Sort Name -uniq | ft Name,CmdletName,ParameterType

2. Nested foreach pipelines.
gcm -type cmdlet | % { $cmdlet = $_; $_ | % { $_.ParameterSets ...


Now that I think about it, I use the first one enough that I should probably
define a new pick filter that grabs the property and automatically attaches
the incoming object as note called "Parent".

There might be easier ways to enable this scenario though. Thoughts?

--
Marcel Ortiz [MSFT]
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


<klumsy@xtra.co.nz> wrote in message
news:1163315899.199338.69860@h54g2000cwb.googlegroups.com...
>
> I just wanted to bring up the issue of gaining access to previous
> objects in
> the pipeline.
>
> that is still a valid goal, because 8 times out of 10, your pipeline
> mightn't rearrange things and there is a direct relationship to a
> parent.. often a one to one, or sometimes a one to many.. i.e
>
> dir *.txt | gc | something
>
> well at something you are dealing with a one to many (one file, has
> many lines of text) , but something just sees a stream of lines of
> text, and the relationship to the file that it came from is lost.. so
> its definately a valid scenario and issue. I have thought about it hard
> and long , and when i have time, i plan a bunch of cmdlets to help aide
> this needed scenario..
>
> Karl
>