Kirk out.

Your one-liner is emitting two separate objects, which is why they appear on different lines. You want one object, so use select instead of foreach and build the object you want, like this:

gci “C:\Program Files\” -recurse -force | ? {!$_.PSIsContainer -and $_.lastwritetime -gt (get-date).addDays(-365)} | select FullName,@{Name=’Date’;Expression={($_.lastwritetime).ToShortDateString()}} | ft

Note if you add -auto to this, and if your filenames are long, you might not see the Date column in your PowerShell host. Lots of ways to solve that though. Here are a few possibilities:
1. Export to csv, open in Excel.
2. Add -Auto, then Convert to string (Out-String -Width 4096) then write to text file (Out-File), then open in notepad.
3. Use an expression for the filename, and if it exceeds some width (say, 60 characters), return a truncated version that has … either at the beginning of the file or somewhere in the middle.

There are of course other ways too, such as stripping off a prefix for the folder you’re searching to make the paths shorter, and I’m sure plenty more, but this should get you started. If you want help with one of these alternatives or some other method, let me know.

Kirk out.

gci “C:\Program Files\” -recurse -force | ? {!$_.PSIsContainer -and $_.lastwritetime -gt (get-date).addDays(-365)} | foreach {$_.FullName, ($_.lastwritetime).ToShortDateString()} | ft -a

Kirk out.

Windows 95 – v4.0 – meh
Windows 98 – v4.1 – good
Windows ME – v4.9 – meh (exception)
Windows 2000 – v5.0 – not bad, some problems
Windows XP – v5.1 – good
Windows Vista – v6.0 – bad
Windows 7 – v6.1

Windows 8 will be v6.2. I think it will be okay once we’re all used to the new “candy” interface.

I saw a building windows 8 blog post a while back explaining the start menu and how it offers better usability. Now that I understand it, I literally deleted all but 6 items. After adding the programs I care about, I have about 15 things on my start menu. Those 15 things are so much easier to select than they would have been on the Win7/XP start menu.

From what I see with Win8, I would happily deploy it alongside my Win7 computers. I doubt we would ever use any Metro apps. Once you take Metro off the table and adjust to the start menu, the way you use the rest of windows feels very much like Windows 7.

Sometimes you need those bad releases to make to good ones so good. I give Vista credit for a lot of Windows 7’s success. I don’t think this is a bad release. The great thing about Win8 is that I forget that I am actually using Win8.

Don’t forget, between your call to Get-Counter and Out-String, you need to use Format-Table * -AutoSize to get the proper results.

For example:

C:\windows\…\powershell.exe -PSConsoleFile “C:\Program Files\…\exshell.psc1″ -Command “Get-Counter -Counter “”\\server\MSExchange RPCClientAccess\RPC Requests”" | Format-Table * -AutoSize | Out-String -Width 120″

I hope this helps.

Kirk out.

Thanks

get-counter -counter “\\server\MSExchange RPCClientAccess\RPC Requests”

If I add | out-string -width 120 it works perfectly fine in the powershell console.

But, if I run it via a perl script which runs powershell as c:\windows\…\powershell.exe -PSConsoleFile “c:\Program Files\…\exshell.psc1″ -command “[above command | out-string -width 120]” things still get truncated at 79…

I agree with supporting a familiar vocabulary using aliases, however I probably wouldn’t create them with a cmdlet-like “verb-noun” name format because I’d be afraid users would use those aliases in published and shared scripts and not just in ad-hoc work. In this specific case, I think the consistency provided through a small library of verbs which benefits the entire PowerShell community outweighs the benefits you’d be providing to scripters by using aliases to add verb substitutes for domain vocabulary familiarity. Learning that PowerShell has only a finite set of verbs and figuring out how to make intelligent guesses using synonyms once you learn some of those verbs is only a small hurdle to overcome. Otherwise, if one team uses Hold as an alias verb for Suspend and another uses Pause, and yet another uses Delay, or Retain, or something else, then we lose the benefits that a small set of verbs provides. Besides, there really is no notion of verbs in aliases as far as command metadata is concerned, so users wouldn’t be able to invoke Get-Command -Verb Hold to discover your alias commands, which could cause further confusion.

Even though I say all that though, I think aliases are great at retaining domain knowledge. Maybe not so much in the verb-noun format though. But I’m always open to discussion to see what possibilities do come out of it, and this is only my opinion on this issue. Food for thought anyway.

Kirk out.

For example, say a product’s users are accustomed to the notion of “holding” a job. “Hold” isn’t one of the PowerShell standard verbs, but “suspend” is.

In order to reconcile this, assuming the two-letter product abbreviation is “BE”, the ISV could export a cmdlet called Suspend-BEJob and an alias to the cmdlet called Hold-BEJob.

The result is that users benefit from the consistency and usability of both the PowerShell verbs AND product-specific terminology.

Consider imo/rmo for Import-/Remove-Module…those two save me personally a ton of time (they’re much less important in PowerShell v3 though). Or consider common ones like gsv (Get-Service), gps (Get-Process), or the breakpoint aliases: gbp, sbp, rbp, all very useful when defining command or variable breakpoints. They’re also useful for line breakpoints, but less since modern scripting environments make line breakpoints easy. If these aliases weren’t defined by default, I’d have to be diligent and organized enough to set up a profile, or a USB key if I work with multiple machines, plus consider RDP scenarios where a USB key wouldn’t be helpful. With those challenges in mind, I’m all for having some aliases defined by default…I just think module authors need to take it easy and stick to the most useful and most frequent commands for this.

The builtin aliases are ok in my opinion because they do serve as a way to ease the transition for users to PowerShell, e.x. dir or cd.

Let the user decide what they want shortened and create their own aliases.