Different results between "PowerShell ISE" and "Run with PowerShell"

1

I have two simple one line "scripts". They check how old are certain files in a certain folders. One displays the output to the screen and the other writes the output to a text file on the desktop. Both ".ps1" script files are saved on the desktop. Running either ".ps1" files using "Run with PowerShell" gets results that are not correct. When running either ".ps1" files via PowerShell ISE the result is different (and correct).

The first script:

cd G:\moveh\back
Get-ChildItem -filter "*.rar" | Foreach-Object {  if ( ((get-date).toshortdatestring() ) -gt ($_.lastwritetime.toshortdatestring() )  ) { "{0}   {1}" -f $_.name,$_.lastwritetime.toshortdatestring()} }

cmd /c pause

The second script:

Get-ChildItem $allfolders | where {$_.Name -notlike "*closed"} | gci -   Recurse -File -filter "Data.rar" | where {( ($_.lastwritetime.toshortdatestring()) -lt ((get-date).AddDays(-1).ToShortDateString() ) ) } | format-table -autosize -Property Directory, Name, LastWriteTime > C:\Users\itsupport\Desktop\Files_2b_updated_DB.txt

An example screenshot with the two different results for the first script:

1

Any ideas why there are different results?

eliko

Posted 2015-05-11T07:53:59.560

Reputation: 55

Answers

1

You're casting dates to strings and it's producing different results in ISE and PowerShell console.

Look at your from073.rar file:

  • ISE date: 10/05/2015
  • PowerShell console date: 5/10/2015

You'd better get rid of .ToShortDateString() and compare dates directly. See this question: Powershell: Comparing dates

Even though the strings are presented differently in ISE and in the PowerShell console the comparison is apples to apples so the results should be the same.

Yep, but your "apples" in this case are character codes, which is I'm sure is not the thing you wanted to compare. Example:

  • 'a' -gt 'b' is false, because character code of a is lower than character code of b.

  • 'ac' -gt 'ab' is true, because character code of a is the same for the both strings, but the next character code of left string (c) is greater than the second character code of the right string (b).

So, when you run your code in ISE that uses dd/mm/yyyy format, your code just compares first dd part and ignores mm/yyyy, because it happens to be the same. And you're getting correct results by pure accident. In PowerShell console date format is mm/dd/yyyy, so your code breaks as it should.

This is my new line:

Get-ChildItem -filter "*.rar" |
    Foreach-Object {
        if((get-date $_.lastwritetime -Format d) -lt (Get-Date -Format d ))
        {
            "{0} {1}" -f $_.name, (get-date $_.lastwritetime -Format d)
        }
    }

But the comparison is not working.

Here you go again: you're using -Format d, which converts date object to string. And you already know what it leads to.

If you want to get files older than one day, your code should look like this (notice, how two DateTime objects compared directly, no strings involved):

Get-ChildItem -Filter '*.rar' |
        Foreach-Object {
            if($_.LastWriteTime -lt (Get-Date).AddDays(-1))
            {
                '{0} {1}' -f $_.Name, $_.LastWriteTime
            }
        } 

beatcracker

Posted 2015-05-11T07:53:59.560

Reputation: 2 334

I have two follow up questions: 1)Even though the strings are presented differently in ISE and in the PowerShell console the comparison is apples to apples so the results should be the same. In screenshot above, in ISE the output displays file names that are not displayed in the PowerShell console and vice versa. Why is that? – eliko – 2015-05-13T12:49:41.763

2.This is my new line: Get-ChildItem -filter "*.rar" | Foreach-Object { if ( (get-date $_.lastwritetime -Format d) -lt (Get-Date -Format d )) { "{0} {1}" -f $_.name, (get-date $_.lastwritetime -Format d)} } But the comparison is not working. I created a test folder with 10 files. The result of the comparison does not include files that are older than a day. Please see example screenshot

– eliko – 2015-05-13T13:12:15.817

@eliko See updated answer. – beatcracker – 2015-05-13T15:00:20.403