Vista - Suggestion: New special variable for pipeline enumeration index

On Apr 16, 10:12*am, MichaelL <goo...@xxxxxx> wrote:If this actually gets any traction I'm guessing that it will
immeditely
be requested that it work in foreach loops too. There it might even
open the door to requests that foreach handle hashtables/dictionaries
using $% would represent the key...

I know every feature is something that someone else might never use.
My initial reaction was based on experience with idiosyncracies of
other languages rather than rational thought about an implementation
in this particular.
I appologize.
My opposition clearly deserves dropping.

On Apr 16, 11:12 am, MichaelL <goo...@xxxxxx> wrote:Scripts, Functions and Script Cmdlets aren't derived from the Cmdlet
class...
To be clear, you're talking about two different things here, the $_ is
the *pipeline output* from the command before (or the automatic
iteration variable) which only exists in scripts. There is no $_ in
cmdlets -- PowerShell takes the output from one pipeline step and
feeds it into the property marked ValueFromPipeline on the next
pipeline step (if there is one) and/or parses it's properties to find
matches for the properties marked ValueFromPipelineByPropertyName ...
Hypothetically, cmdlets (and script cmdlets) could have a property
marked [CounterFromPipeline] or something, *and* provide it as a $%
variable to the PROCESS block on scripts and functions.

However, my objection still stands.

You said earlier that you want $% to be an "integer value holding a
count of the number of items that a pipeline has processed" -- this
number is DIFFERENT for each step of the pipeline at any point in time
(if you don't think so, then you must not have run the script from my
last post). I'm not sure what you mean now by "a counter of operations
on objects."
The $_ is the reason for the existence of the "process" block -- it is
the pipeline output that is being passed into the script/function/
script cmdlet's "process" block as the output is enumerated -- without
it, the process block has nothing to do. Your proposed counter, on
the other hand, is _extra_ information -- information that *could* be
calculated by the process block.

My objection is just that it _should_ be calculated there, since most
commands (by this I mean cmdlets and script cmdlets, scripts, and
functions) won't have a use for it -- no matter how little the work
seems, do it when you need it, not all the time.
As I understand it, what your suggesting would necessarily have the
same cost as having every command implement it's own counter even if
they didn't need it. The commands which do need it, incidentally,
already do calculate it -- as an example, these two lines do basically
the same thing (in Bash and then PowerShell), and both awk and more
count the lines themselves, rather than getting it from the host:

cat *.txt | awk 'NR <= 100' | more

cat *.txt | select -first 100 | out-host -p

Although awk is technically a language all of it's own, it's really
analogous to a cmdlet in powershell -- the shell doesn't track counts,
"awk" the app does.

I'm not saying there's no usefulness in being able to count pipeline
items ... there clearly is. I'm just saying that having the shell do
it for every command is wasteful compared to doing it in the few
commands that need a counter -- In any case, I don't actually have any
say in the matter ;-)

Incidentally, the shell does track all of this sort of information
that you couldn't figure out on your own ... the $MyInvocation
variable has stuff like what line of a script the command was called
from, the position on that line of this specific command, the number
of commands in the pipeline, and which position this command is in,
etc.