Finally from the hints in this article
http://app.en25.com/e/es.aspx?s=1403&e=753&elq=6a3dfdd2d44e43c184f27ab4d4958ead
I have found a simple way to see all properties, not just those deemed suitable 
for console viewing.

For example, instead of just executing Get-ChildItem, execute
Get-ChildItem | Select-Object *
   or
Get-ChildItem | Select-Object * | Out-GridView
because the output can get extensive.

I have to say that this is the first time I have felt that I have found a tool 
to use to really explore the .Net world of PowerShell.

  - Larry

Now I'm confused again!

What is the difference in these two pipelines?

   PS C:>  1,2,"a" | select   | og
   PS C:>  1,2,"a" | select * | og

The first one produces better annotated output that the second one, and that's 
not what I expected.

(select == Select-Object and og == Out-Gridview)

  - Larry

Larry__Weiss wrote:
> Finally from the hints in this article
> http://app.en25.com/e/es.aspx?s=1403&e=753&elq=6a3dfdd2d44e43c184f27ab4d4958ead 
> 
> I have found a simple way to see all properties, not just those deemed 
> suitable for console viewing.
> 
> For example, instead of just executing Get-ChildItem, execute
> Get-ChildItem | Select-Object *
>   or
> Get-ChildItem | Select-Object * | Out-GridView
> because the output can get extensive.
> 
> I have to say that this is the first time I have felt that I have found 
> a tool to use to really explore the .Net world of PowerShell.
> 
>  - Larry

Does anyone have an explanation for what makes these two different?

PS C:> "a" | Select-Object *

                                  Length
                                  ------
                                       1

PS C:> "a" | Select-Object
a

On 1/31/2010 8:40 PM, Larry__Weiss wrote:
> Does anyone have an explanation for what makes these two different?
>
> PS C:> "a" | Select-Object *
>
> Length
> ------
> 1
>
> PS C:> "a" | Select-Object
> a

If you don't specify any arguments for Select-Object, it does nothing 
(it just returns the input object). Thus,

    "a" | Select-Object

is identical to

    "a"

If you don't specify an Out-* cmdlet, PowerShell shows you the default 
output for whatever type of object is returned. In this case you're 
returning a string object, and the default behavior for strings is to 
echo the value of the string.

The default output for Select-Object is to show you a table of the 
specified properties of the object. In the case of the string "a", the 
only property available (non-static) is the Length property.

When you specify "Select-Object *", you're specifying:

    Select-Object -Property *

In other words, "return all properties of the object." For a string, 
there is only one property, and this is what is returned, and displayed 
in the default format of a table.

-- 
David Trimboli
Windows Systems Analyst
Cold Spring Harbor Laboratory

David Trimboli wrote:
> On 1/31/2010 8:40 PM, Larry__Weiss wrote:
>> Does anyone have an explanation for what makes these two different?
>> PS C:> "a" | Select-Object *
>> Length
>> ------
>> 1
>> PS C:> "a" | Select-Object
>> a
> 
> If you don't specify any arguments for Select-Object, it does nothing 
> (it just returns the input object). Thus,
>    "a" | Select-Object
> is identical to
>    "a"
  If you don't specify an Out-* cmdlet, PowerShell shows you the default
> output for whatever type of object is returned. In this case you're 
> returning a string object, and the default behavior for strings is to 
> echo the value of the string.
> 
> The default output for Select-Object is to show you a table of the 
> specified properties of the object. In the case of the string "a", the 
> only property available (non-static) is the Length property.
> 
> When you specify "Select-Object *", you're specifying:
>    Select-Object -Property *
> 
> In other words, "return all properties of the object." For a string, 
> there is only one property, and this is what is returned, and displayed 
> in the default format of a table.
> 

I see now that these two are equivalent
   PS C:> "a" | Select-Object
   PS C:> "a" | Select-Object -ExcludeProperty *

Thanks so much for the illumination!

On rereading the help Select-Object I see where I missed this multifacet nature 
of the Select-Object cmdlet.

NAME
     Select-Object
SYNOPSIS
     Selects specified properties of an object or set of objects. It can also
     select unique objects from an array of objects, or it can select a specified
     number of objects from the beginning or end of an array of objects.

  - Larry

Going back to the two ways to use Select-Object

   PS C:> "a" | Select-Object
   a
   PS C:> "a" | Select-Object *
   Length
   ------
   1

If I added pipe fixtures to each line, what sort of objects are passed down in 
each case?

I'm sure I understand the first case where the objects are just passed along, 
but I don't have a good feeling that I truly understand the second case where 
Properties are selected.  What type of object would be passed downstream?

  - Larry

I would try
 ("a" | Select-Object * ).psobject
("a" | Select-Object ).psobject
and check the TypeNames property

or
("a" | Select-Object ).psbase.getType()
("a" | Select-Object * ).psbase.getType()

On Feb 4, 12:42=A0am, Larry__Weiss <l...@airmail.net> wrote:
> Going back to the two ways to use Select-Object
>
> =A0 =A0PS C:> "a" | Select-Object
> =A0 =A0a
> =A0 =A0PS C:> "a" | Select-Object *
> =A0 =A0Length
> =A0 =A0------
> =A0 =A01
>
> If I added pipe fixtures to each line, what sort of objects are passed do=
wn in
> each case?
>
> I'm sure I understand the first case where the objects are just passed al=
ong,
> but I don't have a good feeling that I truly understand the second case w=
here
> Properties are selected. =A0What type of object would be passed downstrea=
m?
>
> =A0 - Larry

I did all that, and I don't see how it helps me.

If I get anything out of it at all, it seems that

   Select-Object *

creates an abstracted and artificial object that I don't know how to use (except 
to look at the output of the default formatter).

As the song lyrics say, "Is that all there is?"

  - Larry


stej wrote:
> I would try
>  ("a" | Select-Object * ).psobject
> ("a" | Select-Object ).psobject
> and check the TypeNames property
> 
> or
> ("a" | Select-Object ).psbase.getType()
> ("a" | Select-Object * ).psbase.getType()
> 
> On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
>> Going back to the two ways to use Select-Object
>>
>>    PS C:> "a" | Select-Object
>>    a
>>    PS C:> "a" | Select-Object *
>>    Length
>>    ------
>>    1
>>
>> If I added pipe fixtures to each line, what sort of objects are passed down in
>> each case?
>>
>> I'm sure I understand the first case where the objects are just passed along,
>> but I don't have a good feeling that I truly understand the second case where
>> Properties are selected.  What type of object would be passed downstream?
>>

Do you try to solve some problem or are you just curious?

When select-object * new wrapper (PSObject) is created that wrapps all
the properties of the original object.
So that's why you can use it (most of the time) without problems as
you would use original object.

Look here: http://groups.google.ca/group/microsoft.public.windows.powershel=
l/browse_thread/thread/a90e7c1c04fa4837
Some comments might help you.

On Feb 4, 8:51=A0pm, Larry__Weiss <l...@airmail.net> wrote:
> I did all that, and I don't see how it helps me.
>
> If I get anything out of it at all, it seems that
>
> =A0 =A0Select-Object *
>
> creates an abstracted and artificial object that I don't know how to use =
(except
> to look at the output of the default formatter).
>
> As the song lyrics say, "Is that all there is?"
>
> =A0 - Larry
>
> stej wrote:
> > I would try
> > =A0("a" | Select-Object * ).psobject
> > ("a" | Select-Object ).psobject
> > and check the TypeNames property
>
> > or
> > ("a" | Select-Object ).psbase.getType()
> > ("a" | Select-Object * ).psbase.getType()
>
> > On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
> >> Going back to the two ways to use Select-Object
>
> >> =A0 =A0PS C:> "a" | Select-Object
> >> =A0 =A0a
> >> =A0 =A0PS C:> "a" | Select-Object *
> >> =A0 =A0Length
> >> =A0 =A0------
> >> =A0 =A01
>
> >> If I added pipe fixtures to each line, what sort of objects are passed=
 down in
> >> each case?
>
> >> I'm sure I understand the first case where the objects are just passed=
 along,
> >> but I don't have a good feeling that I truly understand the second cas=
e where
> >> Properties are selected. =A0What type of object would be passed downst=
ream?

Just curious and trying to discover all the techniques available for discovery 
using PowerShell.

The mystery to me is that I cannot get anything useful from the ToString() 
method once I pipe an object through
   Select *
For example

PS C:> "a" | % {$_.ToString()}
a
PS C:> "a" | Select-Object   | % {$_.ToString()}
a
PS C:> "a" | Select-Object * | % {$_.ToString()}

PS C:>

  - Larry


stej wrote:
> Do you try to solve some problem or are you just curious?
> 
> When select-object * new wrapper (PSObject) is created that wrapps all
> the properties of the original object.
> So that's why you can use it (most of the time) without problems as
> you would use original object.
> 
> Look here: http://groups.google.ca/group/microsoft.public.windows.powershell/browse_thread/thread/a90e7c1c04fa4837
> Some comments might help you.
> 
> On Feb 4, 8:51 pm, Larry__Weiss <l...@airmail.net> wrote:
>> I did all that, and I don't see how it helps me.
>>
>> If I get anything out of it at all, it seems that
>>
>>    Select-Object *
>>
>> creates an abstracted and artificial object that I don't know how to use (except
>> to look at the output of the default formatter).
>>
>> As the song lyrics say, "Is that all there is?"
>>
>>   - Larry
>>
>> stej wrote:
>>> I would try
>>>  ("a" | Select-Object * ).psobject
>>> ("a" | Select-Object ).psobject
>>> and check the TypeNames property
>>> or
>>> ("a" | Select-Object ).psbase.getType()
>>> ("a" | Select-Object * ).psbase.getType()
>>> On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
>>>> Going back to the two ways to use Select-Object
>>>>    PS C:> "a" | Select-Object
>>>>    a
>>>>    PS C:> "a" | Select-Object *
>>>>    Length
>>>>    ------
>>>>    1
>>>> If I added pipe fixtures to each line, what sort of objects are passed down in
>>>> each case?
>>>> I'm sure I understand the first case where the objects are just passed along,
>>>> but I don't have a good feeling that I truly understand the second case where
>>>> Properties are selected.  What type of object would be passed downstream?
> 

In the article at
http://blogs.technet.com/heyscriptingguy/archive/2009/04/23/how-can-i-work-with-directories-files-and-folders-by-using-windows-powershell.aspx

I find this text:

<#
When you use the Select-Object cmdlet to select certain properties, the object 
that is returned is a custom object that contains only the properties that you 
select and the methods that are common to all Windows PowerShell objects. The 
members of the newly created custom object are shown :

    TypeName: System.Management.Automation.PSCustomObject

Name          MemberType   Definition
----          ----------   ----------
Equals        Method       System.Boolean Equals(Object obj)
GetHashCode   Method       System.Int32 GetHashCode()
GetType       Method       System.Type GetType()
ToString      Method       System.String ToString()
LastWriteTime NoteProperty System.DateTime LastWriteTime=8/17/2008 1:23:10 PM
Name          NoteProperty System.String Name=19287a2cfb60a3bbcca7
#>

What should the ToString() return on such objects?  I never see anything from it 
  when applying it to the output from Select-Object when selecting properties.

  - Larry



Larry__Weiss wrote:
> Just curious and trying to discover all the techniques available for 
> discovery using PowerShell.
> 
> The mystery to me is that I cannot get anything useful from the 
> ToString() method once I pipe an object through
>   Select *
> For example
> 
> PS C:> "a" | % {$_.ToString()}
> a
> PS C:> "a" | Select-Object   | % {$_.ToString()}
> a
> PS C:> "a" | Select-Object * | % {$_.ToString()}
> 
> PS C:>
> 

Again in article
http://blogs.technet.com/heyscriptingguy/archive/2010/02/09/hey-scripting-guy-february-9-2010.aspx
I read

   "In the .NET Framework, all objects have a .ToString() method
    that converts an object occurrence such as a specific file
    into a string."

So, why doesn't

PS C:> "a" | Select-Object * | % {$_.ToString()}

write anything to the console?

  - Larry

Larry__Weiss wrote:
> Just curious and trying to discover all the techniques available for 
> discovery using PowerShell.
> 
> The mystery to me is that I cannot get anything useful from the 
> ToString() method once I pipe an object through
>   Select *
> For example
> 
> PS C:> "a" | % {$_.ToString()}
> a
> PS C:> "a" | Select-Object   | % {$_.ToString()}
> a
> PS C:> "a" | Select-Object * | % {$_.ToString()}
> 
> PS C:>
> 
>  - Larry
> 
> 
> stej wrote:
>> Do you try to solve some problem or are you just curious?
>>
>> When select-object * new wrapper (PSObject) is created that wrapps all
>> the properties of the original object.
>> So that's why you can use it (most of the time) without problems as
>> you would use original object.
>>
>> Look here: 
>> http://groups.google.ca/group/microsoft.public.windows.powershell/browse_thread/thread/a90e7c1c04fa4837 
>>
>> Some comments might help you.
>>
>> On Feb 4, 8:51 pm, Larry__Weiss <l...@airmail.net> wrote:
>>> I did all that, and I don't see how it helps me.
>>>
>>> If I get anything out of it at all, it seems that
>>>
>>>    Select-Object *
>>>
>>> creates an abstracted and artificial object that I don't know how to 
>>> use (except
>>> to look at the output of the default formatter).
>>>
>>> As the song lyrics say, "Is that all there is?"
>>>
>>>   - Larry
>>>
>>> stej wrote:
>>>> I would try
>>>>  ("a" | Select-Object * ).psobject
>>>> ("a" | Select-Object ).psobject
>>>> and check the TypeNames property
>>>> or
>>>> ("a" | Select-Object ).psbase.getType()
>>>> ("a" | Select-Object * ).psbase.getType()
>>>> On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
>>>>> Going back to the two ways to use Select-Object
>>>>>    PS C:> "a" | Select-Object
>>>>>    a
>>>>>    PS C:> "a" | Select-Object *
>>>>>    Length
>>>>>    ------
>>>>>    1
>>>>> If I added pipe fixtures to each line, what sort of objects are 
>>>>> passed down in
>>>>> each case?
>>>>> I'm sure I understand the first case where the objects are just 
>>>>> passed along,
>>>>> but I don't have a good feeling that I truly understand the second 
>>>>> case where
>>>>> Properties are selected.  What type of object would be passed 
>>>>> downstream?
>>

I used Reflector to have a look at type
System.Management.Automation.PSCustomObject and its method ToString().
Here is the result:

public override string ToString()
{
    return "";
}

Obviously the author wanted to return empty string, the question is
'why'. IMHO it is not correct behaviour and I would expect something
meaningful as well as you.
Maybe you should create a bug report...

On Feb 9, 7:53=A0pm, Larry__Weiss <l...@airmail.net> wrote:
> Again in articlehttp://blogs.technet.com/heyscriptingguy/archive/2010/02/=
09/hey-scrip...
> I read
>
> =A0 =A0"In the .NET Framework, all objects have a .ToString() method
> =A0 =A0 that converts an object occurrence such as a specific file
> =A0 =A0 into a string."
>
> So, why doesn't
>
> PS C:> "a" | Select-Object * | % {$_.ToString()}
>
> write anything to the console?
>
> =A0 - Larry
>
> Larry__Weiss wrote:
> > Just curious and trying to discover all the techniques available for
> > discovery using PowerShell.
>
> > The mystery to me is that I cannot get anything useful from the
> > ToString() method once I pipe an object through
> > =A0 Select *
> > For example
>
> > PS C:> "a" | % {$_.ToString()}
> > a
> > PS C:> "a" | Select-Object =A0 | % {$_.ToString()}
> > a
> > PS C:> "a" | Select-Object * | % {$_.ToString()}
>
> > PS C:>
>
> > =A0- Larry
>
> > stej wrote:
> >> Do you try to solve some problem or are you just curious?
>
> >> When select-object * new wrapper (PSObject) is created that wrapps all
> >> the properties of the original object.
> >> So that's why you can use it (most of the time) without problems as
> >> you would use original object.
>
> >> Look here:
> >>http://groups.google.ca/group/microsoft.public.windows.powershell/bro..=
..
>
> >> Some comments might help you.
>
> >> On Feb 4, 8:51 pm, Larry__Weiss <l...@airmail.net> wrote:
> >>> I did all that, and I don't see how it helps me.
>
> >>> If I get anything out of it at all, it seems that
>
> >>> =A0 =A0Select-Object *
>
> >>> creates an abstracted and artificial object that I don't know how to
> >>> use (except
> >>> to look at the output of the default formatter).
>
> >>> As the song lyrics say, "Is that all there is?"
>
> >>> =A0 - Larry
>
> >>> stej wrote:
> >>>> I would try
> >>>> =A0("a" | Select-Object * ).psobject
> >>>> ("a" | Select-Object ).psobject
> >>>> and check the TypeNames property
> >>>> or
> >>>> ("a" | Select-Object ).psbase.getType()
> >>>> ("a" | Select-Object * ).psbase.getType()
> >>>> On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
> >>>>> Going back to the two ways to use Select-Object
> >>>>> =A0 =A0PS C:> "a" | Select-Object
> >>>>> =A0 =A0a
> >>>>> =A0 =A0PS C:> "a" | Select-Object *
> >>>>> =A0 =A0Length
> >>>>> =A0 =A0------
> >>>>> =A0 =A01
> >>>>> If I added pipe fixtures to each line, what sort of objects are
> >>>>> passed down in
> >>>>> each case?
> >>>>> I'm sure I understand the first case where the objects are just
> >>>>> passed along,
> >>>>> but I don't have a good feeling that I truly understand the second
> >>>>> case where
> >>>>> Properties are selected. =A0What type of object would be passed
> >>>>> downstream?

Thanks!
I'm so relieved that I was not totally insane with my persistence pursuing this 
topic!

Now I need to learn about Reflector.

I'll start composing a bug report after seeing if there is one already at
https://connect.microsoft.com/powershell

  - Larry

stej wrote:
> I used Reflector to have a look at type
> System.Management.Automation.PSCustomObject and its method ToString().
> Here is the result:
> 
> public override string ToString()
> {
>     return "";
> }
> 
> Obviously the author wanted to return empty string, the question is
> 'why'. IMHO it is not correct behaviour and I would expect something
> meaningful as well as you.
> Maybe you should create a bug report...
> 
> On Feb 9, 7:53 pm, Larry__Weiss <l...@airmail.net> wrote:
>> Again in articlehttp://blogs.technet.com/heyscriptingguy/archive/2010/02/09/hey-scrip...
>> I read
>>
>>    "In the .NET Framework, all objects have a .ToString() method
>>     that converts an object occurrence such as a specific file
>>     into a string."
>>
>> So, why doesn't
>>
>> PS C:> "a" | Select-Object * | % {$_.ToString()}
>>
>> write anything to the console?
>>
>>   - Larry
>>
>> Larry__Weiss wrote:
>>> Just curious and trying to discover all the techniques available for
>>> discovery using PowerShell.
>>> The mystery to me is that I cannot get anything useful from the
>>> ToString() method once I pipe an object through
>>>   Select *
>>> For example
>>> PS C:> "a" | % {$_.ToString()}
>>> a
>>> PS C:> "a" | Select-Object   | % {$_.ToString()}
>>> a
>>> PS C:> "a" | Select-Object * | % {$_.ToString()}
>>> PS C:>
>>>  - Larry
>>> stej wrote:
>>>> Do you try to solve some problem or are you just curious?
>>>> When select-object * new wrapper (PSObject) is created that wrapps all
>>>> the properties of the original object.
>>>> So that's why you can use it (most of the time) without problems as
>>>> you would use original object.
>>>> Look here:
>>>> http://groups.google.ca/group/microsoft.public.windows.powershell/bro...
>>>> Some comments might help you.
>>>> On Feb 4, 8:51 pm, Larry__Weiss <l...@airmail.net> wrote:
>>>>> I did all that, and I don't see how it helps me.
>>>>> If I get anything out of it at all, it seems that
>>>>>    Select-Object *
>>>>> creates an abstracted and artificial object that I don't know how to
>>>>> use (except
>>>>> to look at the output of the default formatter).
>>>>> As the song lyrics say, "Is that all there is?"
>>>>>   - Larry
>>>>> stej wrote:
>>>>>> I would try
>>>>>>  ("a" | Select-Object * ).psobject
>>>>>> ("a" | Select-Object ).psobject
>>>>>> and check the TypeNames property
>>>>>> or
>>>>>> ("a" | Select-Object ).psbase.getType()
>>>>>> ("a" | Select-Object * ).psbase.getType()
>>>>>> On Feb 4, 12:42 am, Larry__Weiss <l...@airmail.net> wrote:
>>>>>>> Going back to the two ways to use Select-Object
>>>>>>>    PS C:> "a" | Select-Object
>>>>>>>    a
>>>>>>>    PS C:> "a" | Select-Object *
>>>>>>>    Length
>>>>>>>    ------
>>>>>>>    1
>>>>>>> If I added pipe fixtures to each line, what sort of objects are
>>>>>>> passed down in
>>>>>>> each case?
>>>>>>> I'm sure I understand the first case where the objects are just
>>>>>>> passed along,
>>>>>>> but I don't have a good feeling that I truly understand the second
>>>>>>> case where
>>>>>>> Properties are selected.  What type of object would be passed
>>>>>>> downstream?
>