Suggestion: New special variable for pipeline enumeration
index

A while back I posted a suggestion on to MS Connect regarding the
possible addition of a special variable to numerically signify how far
through an iteration of input items a pipeline current is.

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=298135&S
iteID=99

Has any thought been given to implementing this?


In summary I'm lobbying for the addition a new variable (such as $%),
similar to $_, that will would be an integer value holding a count of
the number of items that a pipeline has processed.

It would be really useful to have such a simple means of determining
how far though a pipeline you are.

I'm not sure I see the use for this in the grand scheme of things ...
since you don't know how many there will be, it's of limited use,
right?  But anyway, any cmdlet or script/function that wants to know
how many items it has processed in the current pipeline can already

On Apr 9, 10:23 am, MichaelL <goo...@michaellewis.co.uk> wrote:
> A while back I posted a suggestion on to MS Connect regarding the
> possible addition of a special variable to numerically signify how far
> through an iteration of input items a pipeline current is.
>
> https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=2...
>
> Has any thought been given to implementing this?
>
> In summary I'm lobbying for the addition a new variable (such as $%),
> similar to $_, that will would be an integer value holding a count of
> the number of items that a pipeline has processed.
>
> It would be really useful to have such a simple means of determining
> how far though a pipeline you are.
>
> Michael Lewis

I can't see the page you refer to but I also don't see how knowing
the number of records already processed (which your function can
count itself pretty easily) can tell you how far along you are.
Knowing how many are left would require that you somehow know how
many objects will ultimately be processed.  Such information is, in
most cases I can think of, simply not available.  It's like asking
how many words I will type today.  Moreover, this 'count' could be
different at every step in the pipeline.  Maintenance of all these
counts represents an amount of overhead I'd just as soon not have
every application I write saddled with.  Especially when I can't
think of even one practical use much less enough uses to consider
that it might possibly be justifiable.

In certain circumstances I can see that this would\could be useful but the 
overhead of maintaining it I think is too high.  It would also mean that each 
step in the pipeline had to complete its processing before passing data along 
otherwise subsequent cmdlets wouldn't have an accurate count.  This could be 
a severe performance hit
-- 
Richard Siddaway
All scripts are supplied "as is" and with no warranty 
PowerShell MVP
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"RickB" wrote:

> On Apr 9, 10:23 am, MichaelL <goo...@michaellewis.co.uk> wrote:
> > A while back I posted a suggestion on to MS Connect regarding the
> > possible addition of a special variable to numerically signify how
far
> > through an iteration of input items a pipeline current is.
> >
> >
https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=2...
> >
> > Has any thought been given to implementing this?
> >
> > In summary I'm lobbying for the addition a new variable (such as $%),
> > similar to $_, that will would be an integer value holding a count of
> > the number of items that a pipeline has processed.
> >
> > It would be really useful to have such a simple means of determining
> > how far though a pipeline you are.
> >
> > Michael Lewis
> 
> I can't see the page you refer to but I also don't see how knowing
> the number of records already processed (which your function can
> count itself pretty easily) can tell you how far along you are.
> Knowing how many are left would require that you somehow know how
> many objects will ultimately be processed.  Such information is, in
> most cases I can think of, simply not available.  It's like asking
> how many words I will type today.  Moreover, this 'count' could be
> different at every step in the pipeline.  Maintenance of all these
> counts represents an amount of overhead I'd just as soon not have
> every application I write saddled with.  Especially when I can't
> think of even one practical use much less enough uses to consider
> that it might possibly be justifiable.
> 

On Apr 9, 4:54 pm, RickB <rbiel...@i1.net> wrote:
>
> I can't see the page you refer to but I also don't see how knowing
> the number of records already processed (which your function can
> count itself pretty easily) can tell you how far along you are.
> Knowing how many are left would require that you somehow know how
> many objects will ultimately be processed.  Such information is, in
> most cases I can think of, simply not available.  It's like asking
> how many words I will type today.  Moreover, this 'count' could be
> different at every step in the pipeline.  Maintenance of all these
> counts represents an amount of overhead I'd just as soon not have
> every application I write saddled with.  Especially when I can't
> think of even one practical use much less enough uses to consider
> that it might possibly be justifiable.- Hide quoted text -
>

You're misreading me.
Clearly, knowing how many records are yet to come in the future is not
something that can be know - but that's not what I was suggesting.

Rather I was suggesting that a count be kept of how many records have
been processed thus far, through the current pipeline step.

This would be exactly analogous the the NR variable in awk (another
record processing language).

Granted, if you've not much file or log processing in powershell then
I agree the usefulness of this feature may not be obvious to you.

And as to the overhead of maintaining this count - it's a single
integer which the pipeline could increment every time it calls
ProcessRecord.  By any measure that cant be considered too expensive