Guest post by “The new Windows PowerShell is coming. Actually, Microsoft has just launched a Community Technology Preview of Windows PowerShell version 3, although the final version 3 probably won’t ship until it comes out with Windows 8. It also will be available for Windows 7 and Windows Server 2008 R2. The CTP will install on those OSes.”
Can we maximize PowerShell’s window yet? It irritates me to no end that in this day and age the maximum width of the cmd window is 90 and the maximum width of the PowerShell window is 120. How amazingly stupid of them! What kind of architecture does PowerShell have that doesn’t allow to fully maximize it’s window?
None of the unix shells have that problem, of course.
You can adjust the window width by clicking the window icon on the top left corner and then click the Layout tab and then Window Size (as well as Buffer Size). For Window Size you have Width and Height. To save these settings permanently, create a shortcut of PowerShell to your desktop and right click and then Properties and again go to Layout. I set mine’s width to 160 (on the shortcut) and when I maximize it fully maximizes, you just need to also need to tweak its height a bit. Try 160 by 58.
Edited 2011-12-24 12:58 UTC
also, “mode con: cols=160 lines=3000”
Bonus points for using powershell for determining resolution and font size to calculate the number of columns (lines are automatically scrollbar’d, making it easy to just pick a large number)
Wow, that’s smooth. Not. Why can’t you just resize the window? (Ok, I actually know why, it’s because the Windows console APi sucks balls)
Indeed it is unfortunate that the maximize button on the console host doesn’t actually maximize in both the horizontal and vertical directions. This is not the fault of PowerShell, though, but of the console host that it runs inside. The same host is used for cmd.exe.
In fact this is so retarded that Scott Hanselman, a Microsoft employee, recommends installing a third party console host. Full article here:
http://www.hanselman.com/blog/Console2ABetterWindowsCommandPrompt.a…
Console2 is great, but…
1) try running multiple tabs and killing one of it’s spawned processes.
2) try running some “full screen textmode” programs (ie, those using the console API rather than just writing stdout).
I’m afraid there’s no simple way to get it working perfectly… the Win32 console API was written for speed, backward compatibility and to be similar to hardware PC text video modes, not for flexible goodness :/
Talked to a couple of diehard-windows-pros the other day, and one said:
“Almost no one actually *learn* powershell. Most people, even pros, just copy and paste from the web”
A huge contrast to *nix, where people learn to master their shells, and use them for anything and everything.
e.g. I use bash terminal as my only file-manager.. I fire up thunar on some rare occasions where thumbnails are needed, but have found that bash is almost always faster and more effective than GUI, if one know how to use it.
I believe that this is not the case for powerhell.
on nix we have loads of excellent text editors and powerful tools for command line:) That’s partly what makes it so powerful.
Always so charming.
Aside his comment about Windows Pro’s just copying and pasting power shell source, I didn’t detect any arrogance there.
In fact he was completely spot on about the nix side of things. Nearly everything is written to work well in the CLI. Even many GUI applications have CLI hooks. It’s because of this that using the CLI in nix can be so rewarding and because of this that most nix administrators take the time to learn how to shell script.
DOS never really worked the same as SH did, and thus as nix shells advanced, DOS / CMD always seemed to lag behind.
Now we have PowerShell and I will admit I’ve been pretty impressed with what I’ve seen. However I just don’t have the motivation to learn it as it’s far too wordy. If I need to write that much code to perform simple macros, then I’d rather just copy/paste code or write a fully fledged .NET program and know that it will run on any machine regardless of if Powershell is installed or not.
That’s because you guys have shitty file managers on *nix, and I wouldn’t use them either. But if you ever spent any serious time with Directory Opus on Windows, you’d never make this claim:
http://reviewlagoon.com/viewarticle.php?articleID=50
Of course, if you wouldn’t pay for a quality text editor, you’d never pay for a quality file manager either, especially not for what they’re charging for it. Note: I don’t want to get into a CLI vs GUI pissing contest here, as I use both; I just find it humorous when somebody on a platform full of bad file managers talks about how much file managers suck.
Always so charming.
If you ever used Dolphin on Linux then you’d never have made that claim. :p
Clearly you’ve only ever used GNOMEs default file manager and assumed you’re now an expert on *nix as you seem to miss the point that there’s just as many alternative file managers for Linux as there are for Windows.
Why pay over the odds for a text editor and file manager when your desktop comes with advanced versions of these applications already integrated
KDE comes with KWrite / Kate, which are just as advanced as Notepad++ or EditPlus for Windows.
If you don’t like KDE4 and don’t fancy running Qt apps on your GTK+ desktop of choice, then there’s plenty of GTK+ alternatives too. You see, Linux has this novel concept where you can install 3rd party applications (you hinted at a similar feature in Windows). So if you don’t like the default programs, then change them.
Also don’t moan about a default *nix file manager then harp on about this really cool 3rd party file manager you bought for Windows – because that’s just preaching double standards.
You’re arguing a different point (and one that’s still wrong as per my points above).
His point was the CLI is quicker, not better.
If I want to delete any file according to a pattern match or all the ZIP archives from a directory structure, then it is quicker doing that in the CLI (both in Windows and Linux). For some tasks, the CLI /is/ quicker. That’s not elitism nor arrogance, that’s just a fact of life.
Edited 2011-12-25 11:56 UTC
Only if your file manager of choice doesn’t have decent pattern-based file selection
Few do, however even if they all did, it still wouldn’t help the 2nd scenario I gave about recursive changes cascading through file structure hierarchies
A file manager like xplorer^2 lets you “flatten” a directory hierarchy, letting you achieve a lot of the stuff that usually takes recursive shell commands – of course that means traversing (and keeping dirent info in memory for) the entire hierarchy, which isn’t always a good idea; OTOH it gives you a nice visual overview of what is going to be affected.
Not trying to say that GUIs can do everything a CLI can do (or can always do it as efficiently), they each have their pros and cons – but sometimes it seems like the diehard CLI-only people simply haven’t used a decent file manager
Oh wow, that is impressive.
I would +1 for that alone if I still could.
I think there’s a degree of a learning curve to take into account too: eg by the time I’ve installed and played with something like the above, I could have already done it via the CLI. That’s not to say it would take me a time to learn the GUI – but when you already know how to do these commands by the CLI there’s little motivation to learn another way.
I do use GUI file managers a lot too though. I say that because I really don’t want to sound like a CLI fanboy. For dragging and dropping or selecting a random group of files/folders that don’t have a regular pattern to match, using a GUI is often just more convenient.
Edited 2011-12-26 12:09 UTC
Something I find more comfortable in a GUI than on the CLI is if I need to navigate a lot back and forth in a directory hierarchy, especially when I’m not entirely sure what I’m looking for. The visual overview tends to be slightly faster than a lot of cd and ls commands. And with two-pane navigation, copy and move are a single keystroke away
Another useful feature is x^2’s “mirror browsing” mode – very useful if you have two mostly identical directory hierarchies you want to examine, and a full visual diff isn’t what you need.
I guess the determining factor, for me, is interactive vs. scriptable. If I’m poking around, I tend to prefer a GUI file manager (except if I’m poking around at log files, then a shell and tail tends to win
), if I need to nuke a bunch of temporary files or move a predefined set of files from my server to my workstation, scp is often nicer than firing up a file browser and navigating to the relevant paths.
Though too many take it too far (with barely any hint of “for some tasks”).
Plus, really (particularly for them^), that’s also just a cognitive illusion of life ( http://www.plan9.bell-labs.com/wiki/plan9/Mouse_vs._keyboard/index…. or the points by Moonbuzz here http://www.osnews.com/comments/25359 , /me also trying to get through with similar ones to the CLI faithful …but it’s hard)
(also, at the point of “for some tasks” you are essentially programming the file manager or text editor, so of course text UI is suitable – but then, Google search, Gmaps or… IM & SMS are another kind of UI with also text input, and not really CLI)
Never used Midnite Commander have you? Blows the crap out of any Windows file manager and it’s intergrated text editor makes most windows txt editors cry too.
Edited 2011-12-25 19:23 UTC
You do realize that MC was modeled after tools like Norton Commander (from the good old DOS days), and that there’s several comparable Windows file managers?
Total Commander would probably be the first one that comes to mind, but there’s other powerful ones like xplorer^2, xyplorer, FAR Manager, Directory Opus (ohaithar, Amiga days!), et cetera ad nauseam.
Yes but that does not invalidate his point that it’s a good filemanager that runs on Linux.
Others have pointed out ways of doing this for the console host.
You can also run the ISE, powershell_ise.exe, with the bonus of having Intellisense and other editing features from Visual Studio. It supports custom profiles as well, just as the console environment does, and has an object model ($psise) you may use to customize its appearance/behavior.
The TechNet article barely touches on what’s new in v3, but does link to the PowerShell blog ( http://blogs.msdn.com/b/powershell/archive/2011/09/20/windows-manag… ) which is a better source of info.
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-646T
and
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-644T
is also good.
Related:
http://channel9.msdn.com/Events/BUILD/BUILD2011/?sort=sequential&di…
Edited 2011-12-25 14:49 UTC
I remember the time that the ugly thing was still called Monad. After Monad, I never tried it again.
“CLI with a GUI” WFT…
The whole ecosystem is not really CLI oriented. Doing simple work inside the CLI is hard because many basic tools (e.g. good text editors, text-based browsers) are lacking.
Your point about text-based browsers could be valid, but all of the major text-based browsers have been ported to Windows. We just don’t use them because the many GUI browsers on the platform are much better. But you are completely off about the text editors. There are dozens of programming editors for Windows, including ports of most of the ones available for other platforms, even the text-based ones.
What you might have missed since PowerShell was still called Monad is that more and more of the Windows services have been changed to make them easier to automate with PowerShell. SQL Server even bundles and requires it now. Many existing applications can be automated with it as well, since it operates on the .NET and COM infrastructure that most major applications are built on nowadays.
I think you might be missing the point of all this. PowerShell is just there to give us a good way to control a platform that was already able to be automated. We just didn’t have a good tool that was built around the semantic model of the platform. The old tools were either Unix ports built around files, or COM tools – it’s much easier to automate COM from .NET than the reverse. The fact that there’s a CLI is more of a side-benefit, not the point of it all.
If you really want to you can make changes straight from the CLI using any cross-platform standard text editor, or even develop from scratch. Most people on Windows don’t want to do that though, since their GUI tools are as good or better than those. There’s no problem with that.
Slightly OT : I still have to find a fully satisfying programming-grade text editor for Windows. Notepad++ and SciTE look like stuff from the last century as compared to modern Kile or GEdit…
I’ve heard good things about UltraEdit, but it still feels somewhat weird to pay for a text editor.
Edited 2011-12-25 00:09 UTC
I’ve been using ultraEdit for at least 8years. IMHO, nowt comes even close.
Now it is also available on Linux and OSX.
Yeah, it costs money but in the grand scheme of things, that cost is not huge and one I don’t mind paying. Compared to other tools like XMLSpy it is dirt cheap.
Back to Powershell.
Yep, it does help with automating stuff within windows. This was really needed if Windows was ever going to run headless (sans GUI), something that Unix/Linux has been able to do from before Microsoft was created.
But from my very limited use of it, it does not allow me to anywhere near the amount of things outside the OS area that tools like bash etc can do. I’m still getting to grips with it though and I might be wrong here.
I use UltraEdit and recommend anyone looking for a great Windows-based editor to give it a spin.
As far as paying for it.. Instead of expecting everything to be free, maybe it’s wise to consider that anything worth using on a daily basis may be worth paying for.
I can understand that, but I also make a difference between stuff that I use at work and stuff that I use on my spare time. Advanced text editors fall in the latter category, and so they are not funded by my employer but by my student budget. Said budget being far from infinite, I tend to be careful about purchases that cost above ~$20, especially if it’s as volatile as computer software.
Plus, I do not code on Windows on a daily basis. Most of my work happens on Linux, and I only consider Windows as a side platform that anyone but me uses, and that I must as such support and write documentation chapters for. So it’s not about finding an everyday tool for me, more about finding something which I can use occasionally without too much hassle and which I can recommend to other people.
I recently discovered Geany on Linux, which is quite nice and has a Windows version. Maybe I should give said version a spin.
Edited 2011-12-27 22:47 UTC
OT but I think deserves to be said nonetheless:
I used to feel the same pain as you but recently I found a code editor called Sublime Text 2.
I’ve been using it on Mac and Windows and I absolutely love it!
Give it a try, maybe you’ll like it.
Disclaimer: I’m not affiliated with the developer of this software in any way and I’ll have absolutely no gains whatsoever with this post.
Still ~$60 for a text editor though, so doesn’t help me so much with my dilemma… :/
That being said, I rarely use Windows for anything but gaming and Q&D software compilation + testing these days…
Try PSPad at http://www.pspad.com/en/
I’ve never used another editor since.
Is there a technical reason why Vista isn’t included? I know most users have either already upgraded from Vista, or skipped Vista entirely, but it’s a bit early to make things Win7 only, isn’t it?
Good question. I still have two PCs running Vista (Aero Peek/Snap are available as free downloads). Vista Business still has six years of support left. So what gives?
From the article:
[quote]
CLI with a GUI
Here are some of the highlights of what you^aEURTMll find in the CTP. Newcomers often have difficulty with Windows PowerShell syntax. For example, if they want to retrieve all of the ^aEURoesvchost^aEUR processes, they^aEURTMll run something like Get-Process ^aEUR“svchost. In this case, they should instead run Get-Process ^aEUR“name svchost.
The parameter thing can take a bit of getting used to. In version 3, however, the new Show-Command cmdlet helps make it more obvious what you^aEURTMre supposed to do. Start by running Show-Command ^aEURoeGet-Process^aEUR and you^aEURTMll be rewarded with a pop-up dialog box (see Figure 1).
[/quote]
(grrr… no bbcode I can figure out)
…….anyway, that tidbit is about as close to proof positive that Microsoft does not understand how to write a command line environment, and probably never will.
.. I mean … seriously … A POP-UP!!!!!…. in a CLI?!?!?!?!???
I tried PS briefly at my last employer, and it was just too painful.
I’m over it.
If I every have the misfortune to write script on Windows again I’ll be insisting on python.
Edited 2011-12-26 22:10 UTC