Powershell: A bit confused by documentation regarding working with objects via "gm"

[tetrismasters]

Windows PowerShell

For Windows PowerShell 5.1 issues, suggestions, or feature requests please use the following link instead:
Windows PowerShell UserVoice

This repository is ONLY for PowerShell Core 6 issues.

[tetrismasters]

Your documentation is a piece of garbage made for kinder-garden children/geniuses.

When you suggest me searching System.Diagnostics.Process to get better understanding of how Get-member works - like, why?

Basically to work with PS you either need to be a programmer that understands .NET or a moron that can copy and paste.

I got the idea that it's object oriented - cool. Now there's no way for me to understand how those objects are built or breaking them up for my custom use unless I learn .NET. Cause there's no information on this regard except .NET documentation and some kinder-garden help for Powershell that allows you to understand how copy-paste works. What an awesome tool.

[DWSR]

Windows PowerShell

For Windows PowerShell 5.1 issues, suggestions, or feature requests please use the following link instead:
Windows PowerShell UserVoice

This repository is ONLY for PowerShell Core 6 issues.

What is the purpose of commenting this snippet from the Readme?

Your documentation is a piece of garbage made for kinder-garden children/geniuses.

If we could stop with the insults and get to the actual feedback, that would be great.

When you suggest me searching System.Diagnostics.Process to get better understanding of how Get-member works - like, what the actual fuck?

I think you're misunderstanding the documentation. The examples on the Get-Member page show how you can use Get-Member on various different output types. System.Diagnostics.Process is the output type of the Get-Process cmdlet.

Basically to work with PS you either need to be a programmer that understands .NET or a moron that can copy and paste.

I got the idea that it's object oriented - cool. Now there's no way for me to understand how those objects are built or breaking them up for my custom use unless I learn .NET. Cause there's no information on this regard except .NET documentation and some kinder-garden help for Powershell that allows you to understand how copy-paste works. What an awesome tool.

Being a language and utility that's based on .NET, what were you expecting? There is a tremendous amount of help content around PowerShell of which the MSDN site is a central part. This is the same as learning Python and being expected to understand the modules provided as part of the standard distribution or at least where to get information on them. The only real difference is that the standard library for Powershell is all of .NET

[tetrismasters]

The purpose is me ranting. No good reason, just needed a place to spill it
out.
NVM, great documentation + all and all intuitive to understand.

With all honesty - sorry for the rant, but to be quiet frank this is
nowhere real to be better than BASH, as advertised by creators who trash
BASH both in the book and in the video-course. In reality the core audience
of the product are people who know how to copy-paste. And people who know
.Net. I'm done, if you can delete it that would be great.

On Mon, 18 Mar 2019 at 16:06, Brandon McNama [e-mail]
wrote:

Windows PowerShell

For Windows PowerShell 5.1 issues, suggestions, or feature requests please
use the following link instead:
Windows PowerShell UserVoice
https://windowsserver.uservoice.com/forums/301869-powershell

This repository is ONLY for PowerShell Core 6 issues.

What is the purpose of commenting this snippet from the Readme?

Your documentation is a piece of garbage made for kinder-garden
children/geniuses.

If we could stop with the insults and get to the actual feedback, that
would be great.

When you suggest me searching System.Diagnostics.Process to get better
understanding of how Get-member works - like, what the actual fuck?

I think you're misunderstanding the documentation. The examples on the
Get-Member
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-member?view=powershell-6
page show how you can use Get-Member on various different output types.
System.Diagnostics.Process
https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=netcore-2.2
is the output type of the Get-Process cmdlet.

Basically to work with PS you either need to be a programmer that
understands .NET or a moron that can copy and paste.

I got the idea that it's object oriented - cool. Now there's no way for me
to understand how those objects are built or breaking them up for my custom
use unless I learn .NET. Cause there's no information on this regard except
.NET documentation and some kinder-garden help for Powershell that allows
you to understand how copy-paste works. What an awesome tool.

This is the same Being a language and utility that's based on .NET, what
exactly were you expecting? There is a tremendous amount of help content
around PowerShell of which the MSDN site is a central part. This is the
same as learning Python and being expected to understand the modules
provided as part of the standard distribution or at least where to get
information on them. The only real difference is that the standard library
for Powershell is all of .NET

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-473923580,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfIxH5sRee30YcYuyqJS7QE3kR2TFSks5vX51mgaJpZM4b50f2
.

[vexx32]

@tetrismasters I can understand the frustration to some degree, but wouldn't it be much better served by pointing out where it could be made better? 🙂

[tetrismasters]

Well, first of all I'm new to PS and I can simply be wrong. So I beg an
apology in advance. Though to my understanding the way objects and tools
provided to work with those objects are presented a bit copy-pasty. At
least as far as "Powershell in depth" and help go describing them. Like -
I'm trying to understand what I'm not understanding and I'm failing to do
so. Basically you can give Get-Member and output of a cmdlett that will be
parsed as objects and combined all together as methods, properties, etc but
to parse a specific object to get-member - nah, let's not even mention this
possibility. We only work in bulks apparently :). Like - isn't it the next
question that is popping in your head when you are learning it - how do I
transfer a single object to "gm" instead of the whole group of objects
(get-process/get-service/import/etc) which I have zero ways defining what
goes in (except filters I guess?) - so the information "gm" gives me is
generalized to say it kindly :).

the core reason of the rant - Jeffrey and Don trashing BASH openly again
and again while it's so much more convenient than Powershell. Yes, its text
and not objects and objects are way cooler - I agree. But as long as you
don't shove at me the way I can separate a single object from
"get-service/get-process" and pipe it to get-member - as far as I'm
concerned the object oriented part is useless - at best. I don't want to
remember what sticks where (and I have a pretty good memory - it's not what
bugs me). I want to understand and cut to the flash. As far as I saw it is
presented to some degree, and I could be wrong generally, but again as far
as I saw, those aren't the things that a thrown at you as a student of PS
and those are most important things to understand, cause those are the
basics of the PS. Those are the building bricks. Instead of it PS is
presented as "something you don't need to be a programmer to use" and it
feels really flat to me - cause it seems as the explanations are simplified
to not fear "non programmer" folk away (and I didn't know what IP address
is three years ago working at construction. So if this feels flat to me -
either I'm a moron (possible) or it was simplified too much (my bet)). So
now I have to stop and try to understand - am I a moron, who doesn't
understand the written English or those things are simply not being
mentioned at the the needed depth both in the help and in the book written
by authors of PS. Which is - frustrating :). Cause I don't want to move
further if I missed the basics. It feels like I did but nothing it the book
says so - except as I've said "kindly" in the first place - "for more
understanding search: ". And the only result
you get is related to .Net. So the idea of not being a programmer (have
nothing against of being a programmer for using PS) is quite misleading :)

On Mon, 18 Mar 2019 at 17:28, vexx32 [e-mail] wrote:

@tetrismasters https://github.com/tetrismasters I can understand the
frustration to some degree, but wouldn't it be much better served by
pointing out where it could be made better? 🙂

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-473959481,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfIybAxYjw8AUHWd0yEHstU5d55a88ks5vX7CigaJpZM4b50f2
.

[vexx32]

Okay, let's see....

So, with Get-Member, the way you'd give it a single object is essentially identical to how you'd give it multiple. Really, the only difference is what you choose to give it. Get-Member gives you an outline of everything that object can get for you, but it doesn't typically get that data for you.

If you're looking for, for example, "I want a list of the object(s) properties and what the value is for each of them", Get-Member can only really tell you the property _name_. If you want name and value all neatly laid out for you to see, it might be more effective to look at it by piping to Format-List. And if you just want to select a single item from a collection there are several ways to do so. Here's one:

# (or pipe to `Get-Member` if you prefer!)
Get-Process | Select-Object -First 1 | Format-List

In short... Get-Member doesn't control what goes in, the cmdlets before it do, and in many ways you do. It can definitely be a bit much at first, I agree, and reading through documentation isn't for everyone. (I personally enjoy just reading docs endlessly and have done so for PowerShell, .NET, SkiaSharp, etc., etc. but that's really not an approach most people find friendly.)

Bash is a great tool, but in a sense it can't do a whole lot. Take away the discrete binaries, and Bash itself is pretty limited. In comparison, PowerShell has a _ton_ built in, and if you want to call back to the native utilities and do the text processing instead, that's still available. I've not really heard that many folks openly _trashing_ Bash, but I can definitely see that in some ways a few folks tend towards speaking that way and it can be very easily misunderstood without further context. Without knowing exactly what you've heard and who you've seen, I can't really say more. 🙂

I disagree that PowerShell is something you "don't need to be a programmer to use".... _sort of_. It's a fantastic entry point, even if you've never learnt any programming before. It's very flexible, you don't need to go through the hassle of compiling anything, it's largely a standalone tool with all its dependencies built in, very little to worry about from the user end.... but you _will_ end up learning bits and pieces of programming as you go, and you'll need to.

In many ways, you can't progress beyond certain points in learning PS until you've grasped some concepts. And, largely, I think that's OK-- it's better to require some understanding of the tool. PS is a _ridiculously_ powerful tool, and it needs to be understood on a certain level before you know enough to completely wreck a system in most cases, and I think that's probably _wise_.

If you happen to be the sort of fellow who learns most effectively by doing and experimenting, I've put together a bit of a guided tour of the things PowerShell can do and how you can work with it, if you're interested.

http://aka.ms/pskoans

Of course, if you have any questions... don't hesitate to ask. 😄

[DWSR]

Basically you can give Get-Member and output of a cmdlett that will be parsed as objects and combined all together as methods, properties, etc but to parse a specific object to get-member - nah, let's not even mention this possibility. We only work in bulks apparently :)

In this specific example, what is the goal of splitting out a single object? All objects returned are expected to be of the same type, so whether you use gm on an entire collection of [System.Diagnostics.Process] or a single one will yield you the same result.

Jeffrey and Don trashing BASH openly again and again while it's so much more convenient than Powershell.

It is more convenient than Bash. What you're thinking of Bash and what Bash actually is are two separate things. Bash does not include commands like find, for example. Those are usually packaged up as part of coreutils or, more generally, GNU Utils. Whether you find Bash + gnutils to be more convenient than pwsh is, of course, subjective.

But as long as you don't shove at me the way I can separate a single object from "get-service/get-process" and pipe it to get-member - as far as I'm concerned the object oriented part is useless - at best.

Again, I don't see what the purpose of getting a single object out of the pipeline is. Perhaps you could elaborate?

The pipeline (chains of commands) is always assumed to be working on collections of objects that flow from left to right. If you want to inspect the contents of a collection, you can easily save the output to a variable and then iterate over that variable. For example:

$ps = Get-Process
$ps[0] # Get details of the first process

However, you could also do this to get the same result:

Get-Process | Select -First 1

Or even something fun like this:

# Get all processes with an ID greater than 80.
Get-Process | Where-Object { $_.Id -gt 80 }

I want to understand and cut to the flash. As far as I saw it is presented to some degree, and I could be wrong generally, but again as far as I saw, those aren't the things that a thrown at you as a student of PS and those are most important things to understand, cause those are the basics of the PS.

You seem to be trying to run before you can walk (which I can understand to be frustrating!). The pipeline in pwsh is a very powerful tool and you seem to be trying to tease it apart without fully understanding it. Perhaps some further reading may help? @vexx32 may have some suggestions there.

[powercode]

@tetrismasters Maybe you can fill us in with what you have read so far when trying to learn PowerShell. That way we can be more helpful in suggesting the next step.

[tetrismasters]

Guys, I truly appreciate your replies. I don't think PS is bad - quite the
opposite. I was actually surprised that it's not as bad as I thought it
would be - more than that it seems kinda good and therefore I want to learn
it properly. I'm not comparing BASH to PS - Jeffrey and Don do - the guys
who are responsible for PS3 if I'm not mistaken :)

why would I want to put a single object to get-member instead of the array
that "get-process" gives me - just as a proof of a concept. To assure that
I'm understanding correctly what's happening. The problem is not how it
works but how it is mentioned in docs. The results being the same for a
single object and for the collection of objects of the same type was my
final guess but here's the problem - it was a guess :). It's not mentioned.
Quite the opposite (unless - English bad), in "Powershell in Depth" its
described as get-member gives you all the methods and properties of objects
that get-service/whatever is piping to it. That makes you think that
services/processes can have different attributes and get-member will give
you the combined results of all the different methods and properties of the
objects that were piped to it. So the next logical thing for you (as a
student) to do is piping a single process to get-member (which I've
described as "I guess you can make it with a filter") and check if it gives
you a different result. And you totally described how it can be done and
I'm totally gonna try it tomorrow :)

The book I'm reading is "Powershell in Depth" by Don Jones and Jeffrey
Hicks. It's not bad, but as I've said it feels a bit of an "under-kill".

Anyway, sorry for the rant, thank you for your time. Brandon answered my
question - the results being the same for a single process and for
get-process. Which is, again, not something you cannot think of - it's just
not something that is not mentioned and to me, it was the first thing
popping in my mind - will it work the same for a single object. M.b. I'm
the only one who's brain is twisted like that or I'm just dumb not
understanding the obvious things. Or too Russian :). It is all a
possibility.

And I guess I'm being annoying regarding this part, because to me this
feels like a cornerstone of PowerShell. As the most important concept to
understand.

Again thank you all for your time and - I do enjoy PowerShell itself :)

On Mon, 18 Mar 2019 at 18:43, Staffan Gustafsson [e-mail]
wrote:

@tetrismasters https://github.com/tetrismasters Maybe you can fill us
in with what you have read so far when trying to learn PowerShell. That way
we can be more helpful in suggesting the next step.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-473998150,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfI-3OgZP6uRytS8pyqdjkKNBJ6rbsks5vX8I2gaJpZM4b50f2
.

[rkeithhill]

That makes you think that services/processes can have different attributes and get-member will give
you the combined results of all the different methods and properties of the
objects that were piped to it.

As a better example of this, find a folder that has both files and subfolders in it and then execute:

Get-ChildItem <path-to-that-folder> | Get-Member

You should see output for FileInfo and DirectoryInfo objects - one for each type of object - not each instance of object. That IMO would actually be very annoying. I only need to see object members once for each type.

BTW if you want to see type info for every object instance you can do this (which I do from time to time):

Get-ChildItem <path-to-that-folder> | Foreach-Object GetType

[tetrismasters]

Thanks, Keith, appreciated!

On Mon, 18 Mar 2019 at 20:15, Keith Hill [e-mail] wrote:

That makes you think that services/processes can have different attributes
and get-member will give
you the combined results of all the different methods and properties of the
objects that were piped to it.

As a better example of this, find a folder that has both files and
subfolders in it and then execute:

Get-ChildItem | Get-Member

You should see output for FileInfo and DirectoryInfo objects - one for
each type of object - not each instance of object. That IMO would
actually be very annoying. I only need to see object members once for each
type.

BTW if you want to see type info (just name) for every object you can do
this (which I do from time to time):

Get-ChildItem | Foreach-Object GetType

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-474039249,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfI87ncNXFW1-qylshZwSE6yfRSoW-ks5vX9exgaJpZM4b50f2
.

[powercode]

And if you really want it for the object you have, you can bypass the pipeline by using

Get-Member -InputObject $yourVariable

That may be useful when you need the type of a collection.

[tetrismasters]

Staffan, I've tried this on but only now I see how it is different from
get-service | gm.
guys thanks a lot! I needed this confirmation.
sorry for the rant. I thought it's more of "internal use" feedback that no
one reads. It wasn't my intent to create a giant shit storm.

On Mon, 18 Mar 2019 at 22:15, Staffan Gustafsson [e-mail]
wrote:

And if you really want it for the object you have, you can bypass the
pipeline by using

Get-Member -InputObject $yourVariable

That may be useful when you need the type of a collection.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-474082794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfIxS2z7TLDCPsRpkrCw_TS_vgoP8Iks5vX_PfgaJpZM4b50f2
.

[pougetat]

Hey @tetrismasters,

Yep we do read it and we try to help out when we can :). The powershell team is a great open source community and I've tried joining a few so I have some (albeit limited) experience in how tough it can be to find one that is truly "open".

It's great to see that this conversation ended on a higher note than it started on and I learned a lot reading the responses from my fellow collaborators.

With that in mind could you change the name of the issue to perhaps something a bit more positive ? :)
Perhaps something along the lines of "Documentation could be improved" ?

Cheers 😃

[tetrismasters]

Sure. And thank you again :)

On Tue, 19 Mar 2019 at 10:44, pougetat [e-mail] wrote:

Hey @tetrismasters https://github.com/tetrismasters,

Yep we do read it and we try to help out when we can :). The powershell
team is a great open source community and I've tried joining a few so I
have some (albeit limited) experience in how tough it can be to find one
that is truly "open".

It's great to see that this conversation ended on a higher note than it
started on and I learned a lot reading the responses from my fellow
collaborators.

With that in mind could you change the name of the issue to perhaps
something a bit more positive ? :)
Perhaps something along the lines of "Documentation could be improved" ?

Cheers 😃

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/9159#issuecomment-474248299,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoSfIxz5Luobu2-YtZeUqLRmrHvECV8Hks5vYKNogaJpZM4b50f2
.

[SteveL-MSFT]

It's really great to see all the community members help out new users where it can be frustrating learning something new. One of the downsides to PowerShell team members writing documentation is that we don't see it from a beginner's point of view and will leave out details we've internalized.

I would suggest using https://powershell.org/forums/ for general PowerShell usage questions.