none
WMI Scripting Noob

    Question

  • I am trying to script a way to check to see if they have a certain driver then what architecture they have.

    To see if they have the right NIC I use.

    Get-WmiObject -Class CIM_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"

    Then to see if they have a 64 bit arch I use.

    Get-WmiObject -Class Win32_OperatingSystem | Select-Object OSArchitecture

    I tried to do this just for testing to see if I could get it to work

    $nic = Get-WmiObject -Class CIM_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"
    $x = "Broadcom NetXtreme Gigabit Ethernet"
     if ($nic -eq $x) {Write-Host "Hello my name is Bob"}
       elseif ( $nic -ne $x) {Write-Host "Hello, my name is Troy"}

    But it didnt work any idea on what do to?

    And on a sub note does powershell work with devcon?

    • Moved by Bill_Stewart Tuesday, March 25, 2014 2:36 PM Abandoned
    Thursday, September 26, 2013 4:26 PM

All replies

  • Assuming that a NIC with that name exists, $nic will be a reference to a System.Management.ManagementObject instance (or to an array of such objects, if multiple results were returned).  If that NIC wasn't found, $nic will be null, instead.  You can test for this with if ($nic), or if ($null -ne $nic), etc.

    $nic = Get-WmiObject -Class CIM_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"
    if ($null -ne $nic) {Write-Host "Hello my name is Bob"}
        else {Write-Host "Hello, my name is Troy"}


    • Edited by David WyattMVP Thursday, September 26, 2013 5:04 PM
    • Proposed as answer by jrv Thursday, September 26, 2013 5:44 PM
    Thursday, September 26, 2013 4:55 PM
  • Very close.  Since you already know the name of the adapter you canjust do this:

    if(Get-WmiObject Win32_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"){
        'Adapter found!'
    }else{
        'Adapter not found'
    }


    ¯\_(ツ)_/¯

    • Proposed as answer by jrv Thursday, September 26, 2013 5:19 PM
    Thursday, September 26, 2013 4:57 PM
  • Similarly for OS architecture we can more easily use this.

    if([environment]::Is64BitOperatingSystem){
        'Operating System is 64 bit'
    }else{
        'Operating System is 32 bit'
    }


    ¯\_(ツ)_/¯


    • Edited by jrv Thursday, September 26, 2013 5:00 PM
    • Proposed as answer by jrv Thursday, September 26, 2013 5:19 PM
    Thursday, September 26, 2013 5:00 PM
  • DEVCON in PowerShell????  For what?

    All commandline programs work at a PowerShell prompt; it works almost completely like CMD (used to be DOS but DOS is dead)


    ¯\_(ツ)_/¯

    Thursday, September 26, 2013 5:02 PM
    • Proposed as answer by jrv Thursday, September 26, 2013 5:19 PM
    Thursday, September 26, 2013 5:19 PM
  • This method is not wrong but it is confusing.

    if ($null -ne $nic) {Write-Host "Hello my name is Bob"}
        else {Write-Host "Hello, my name is Troy"}

    First it is formatted badly and can get lost in the overall code.  Lining up parens is easier for the eyes to follow.  It also makes it easier to find mistakes.

    if($null -ne $nic){
         Write-Host "Hello my name is Bob"
    }else{
         Write-Host "Hello, my name is Troy"
    }

    Note how the block stands out.  It is easy to see the structure and to guess at how it will execute.  Most early 'C' and C++' editors and 'pretty' print routines used this alignment.  It is one of three suggested methods.

    Method # 2 looks like this:

    if($null -ne $nic)
    {
         Write-Host "Hello my name is Bob"
    }
    else
    {

         Write-Host "Hello, my name is Troy"
    }

    This, also, is easy to read and to see the structure. It too is easier to debug. The third method is almost never used but some still issue it. It is not well accepted currently.

    Method #3

    if($null -ne $nic)
          {

               Write-Host "Hello my name is Bob"
          }else{
               Write-Host "Hello, my name is Troy"
         }

    It looks uncomfortable to me but is does work.

    The next issue that is useful to knpw is how to test for null.  In VB languages we use IsNull() .  This is also use in SQL dialects and numerous other language standards particularly Clocksin Mellish (an ISO standard) derived languages.

    In C-like languages null testing is simplified.  Null and uninitialized variables test as false by design.  0, anempty string and annj empty or zero pointer all test to null.  Thisis a convenience in C because we can just checl strings before using them

    if(mystring){printf("Your string is %s',mystring}

    In PowerShell we can do the same thing. This, too, is by design.

    if($nic){'Nic has a value'}else{'nic is null'}

    The above is legitimate for very short tests on oneline.  Be careful it is very simple and very clear so it is not interpreted as the beginning of an if block.

    My version above just tests the outcome of the WMI call.  If you just want to know if something exisits and don't care about the object after wards then this is explicit and usual:

    if(Get-WmiObject Win32_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"){
        Write-Host 'Adapter found!' -fore green
    }else{
        Write-Host 'Adapter not found' -fore red
    }

    If you do need the results then here is how we do it in C/C++/C# and PowerShell:

    if($nic=Get-WmiObject Win32_NetworkAdapter -Filter "name='Broadcom NetXtreme Gigabit Ethernet'"){
        Write-Host ('[Adapther={0}] [DeviceID={1}]' -f $nic.Name,$nic.DeviceID) -fore green
    }else{
        Write-Host 'Adapter not found' -fore red
    }

    You can see that adding the results capture in also allows us to test. The resault of an assignment in all C-like langugaes and in PowerShell is the assignment or l-value. (left -value)

    if($x=99)

    This evaluates to 99 which is true.

    if($x=0){'it is true'}else{'it is false'}

    What is this one:

    if(3*2+9/2-10.5){'it is true'}else{'it is false'}

    Happy scripting.


    ¯\_(ツ)_/¯




    • Edited by jrv Thursday, September 26, 2013 6:14 PM
    Thursday, September 26, 2013 6:12 PM
  • I'm aware of that.  I just copied and pasted the OP's code and changed the conditional expression to test for $null instead of comparing $nic to a string.  I didn't bother reformatting it.

    As for methods of testing for null values, it's personal preference.  I used the "if (variable)" style a lot when dealing with pointers in C++, because pointers were either zero or not.  In .NET and PowerShell, I prefer to explicitly test for null, because sometimes non-null values can still evaluate to False in a conditional (which you basically demonstrated with the ( if(3*2+9/2-10.5){'it is true'}else{'it is false'} ) example):

    $variableToTest = 0

    if ($variableToTest) { "True" } else { "False" } # False: $variableToTest is non-null, but zero evaluates to
    # False as a boolean

    if ($null -ne $variableToTest) { "True" } else { "False" }
    # True: $variableToTest is not a null reference.

    In PowerShell, there is technically a difference between testing for ($null -ne $something) and ($something -ne $null) as well, when dealing with collections, which is why I try to remember to put $null on the left if I'm specifically checking for whether a variable is a null reference:

    $collection = @($null, $null, $null) if ($null -ne $collection) { "True" } else { "False" }
    # True: $collection is not a null reference; it's a collection that happens
    # to contain only null references.

    if ($collection -ne $null) { "True" } else { "False" }
    # False: There are no non-null elements contained in the collection.



    Thursday, September 26, 2013 6:28 PM
  • No - its symmetrical.  It just reads different to you because you don't think in logic.  You think in words.  I think like  computer - always have.

    Everything in scripting is optional and preference however, if you want to be understood you need  consistency.  Testing the 'truthy-ness' inthisway is more explicit inmost cases.  Testing agains an object canfail.  I think RObs blog has a set of examples where that habit blows up in odd ways.

    "if x = false" is convoluted.  Charles Dodgson would turn over in his grave. 


    ¯\_(ツ)_/¯

    Thursday, September 26, 2013 8:57 PM
  • Run the code I posted and see for yourself.  Those conditionals, though "symmetrical", do return different results in PowerShell.
    Thursday, September 26, 2013 9:47 PM
  • Run the code I posted and see for yourself.  Those conditionals, though "symmetrical", do return different results in PowerShell.

    Yes - that will happen in any language when you choose to ignore how the filter code works.

    You are testing against a collection of nulls.  That is not the same as a null.  A collection of nulls is a true set.  It is NOT a null set.

    I said the object must be null and not a collection that is not empty.

    This, however, is false:
    if(@($null)){'true'}else{'false'}

    In PowerShell an array of one is evaluated as a singleton. This is an accelerator or like an accellerator.  I believe Payette documents it and why in his first book.


    ¯\_(ツ)_/¯

    Thursday, September 26, 2013 9:59 PM
  • I'm not sure how demonstrating the way PowerShell operators work qualifies as choosing to ignore how they work.  :P  I know exactly why those conditionals work the way they do.  I've given a clear explanation as to why I use (if ($null -ne $variable)) syntax.  Other options give results that I don't want, on occasion.


    Thursday, September 26, 2013 11:04 PM
  • Here's an example of using the devcon utility via PowerShell (I haven't used this myself, so I can't vouch for it):

    http://www.powergui.org/thread.jspa?threadID=11472

    Now that I've posted something useful, I'm going to go off topic for a moment.

    David and jrv - I just wanted to voice my appreciation for your arguments and bickering. I've learned more about why things work the way they do from reading these threads than from pretty much any other single source. My thanks to you both.

    Don't retire TechNet! - (Maybe there's still a chance for hope, over 12,000+ strong and growing)

    Friday, September 27, 2013 12:05 AM
  • Ha! Mike - who knew.

    Call us Siskel and Ebert.


    ¯\_(ツ)_/¯

    Friday, September 27, 2013 12:10 AM
  • Friday, September 27, 2013 12:14 AM
  • We could do it on YoutTube - The Dave And Jim Technical Bitching Hour.  I am not sure we would get much of a following.

    ¯\_(ツ)_/¯

    Friday, September 27, 2013 12:26 AM
  • Anyway - this is a dead thread.  The OP hasn't looked at or responded to the suggestions. I also think there is little else we can provide here. Whichever test approach is used will work and the DEVCON thing is handled as much as it can be.

    G'nite all.


    ¯\_(ツ)_/¯

    Friday, September 27, 2013 12:29 AM
  • Parting foo for thought:

    PS C:\scripts> Remove-Variable junk -force -ea 0
    PS C:\scripts> $junk -eq $false
    False

    But it is true that an null variable is also false but the result says it is not false.  Explain please?

    This proves that it is true that $junk is false:

    if($junk){'True'}else{'false'}


    ¯\_(ツ)_/¯

    Friday, September 27, 2013 12:38 AM
  • This proves that it is true that $junk is false:

    if($junk){'True'}else{'false'}


    ¯\_(ツ)_/¯

    That's incorrect, and is the source of the confusion.  What that actually proves is that $junk becomes $false when it is coerced to a Boolean value.  When you call if (<expression>), if the expression doesn't already produce a Boolean value, PowerShell just casts whatever came out of that expression to [bool].  For most reference types, null becomes false and non-null becomes true.

    $null -eq $false
    # False
    
    [bool]$null -eq $false
    # True

    Friday, September 27, 2013 1:35 AM
  • Thank you - I said that a few days ago in another life.  All nulls are false.  All empty collections are false.  All zero numerics are false.  All empty strings are false.  How they all get there is up to the compiler/interpreter and the rules.  Coercion to bool is one way of forcing this.

    It is by design and it is by result as the logic amazingly holds across most of the mathematical universe.


    ¯\_(ツ)_/¯

    Friday, September 27, 2013 1:58 AM
  • No one is arguing that.  I stated that when I am testing, specifically, for a null reference, I've settled on if ($null -eq $someVariable).  That's what gives me the correct result every time in PowerShell, regardless of what is contained in $someVariable.  Both of the other options(  if ($someVariable), and if ($someVariable -eq $null) ) can produce unwanted results if the variable happens to be a value type or a collection, respectively.

    That's just how the language is written.  I work around it, rather than trying to force my old C++ style into code where it's not the best option.

    Friday, September 27, 2013 2:17 AM
  • Wow - I cannot suss that at all.  It may seem natural to you but it feels very awkward to me.

    Well...if it makes you happy.


    ¯\_(ツ)_/¯

    Friday, September 27, 2013 2:38 AM