Jeffrey Snover claims Microsoft demoted him for inventing PowerShell PowerShell inventor Jeffrey Snover has aired some grievances about how his indispensable tool once got him demoted. The Microsoft Technical Fellow discussed the incident in a weekend Twitter thread that started when controversial investor Peter Thiel discussed the virtues of courage. "Courage is a key characteristic of future …
with the added twist that us poor *nix bods - looked down on for years - suddenly leapfrog the seasoned windows admins (who have said more than once that it's unfair) who ran a mile from the CLI.
Almost everything you want to do in Windows Admin is now done with a PSE of some sort.
"with the added twist that us poor *nix bods - looked down on for years - suddenly leapfrog the seasoned windows admins (who have said more than once that it's unfair) who ran a mile from the CLI."
Not really. I have been a Windows admin for at least a couple of decades and always tried to script repeatable or automated tasks. Before powershell it was using CMD and 3rd party utilities for most of it.
I am not militant either way and always just use the most appropriate tool for job.
For quick one off changes to settings, use the GUI. For something you want to repeat or automate create a script. Sometimes use both. Use the GUI to make the change you want to automate, then dig into the system to see what it actually changed so you can script it.
It does if you turn on long path name support:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
REG_DWORD LongPathsEnabled = 1
Works on all builds since 14393.
Not sure why it isn't enabled by default now.
Earlier builds, shorten paths using NET USE or SUBST or use robocopy.
So I started out with Windows, then moved away to Linux, and now where I am while I use Linux 100% of the time but I need to provide support to Windows machines. Most of the time the PowerShell is helpful in doing that.
I think you are right that the syntax isn't great. It feels, sometimes to me, that commands given are like a weird pirate copy of the usual DOS prompt you used to get with Windows. It doesn't feel that intuitive compared to the language you use on the Linux CLI.
But it's miles ahead of what was possible with DOS, and the fact that even with it's ugliness it allows us to actually do things in Windows now. And that makes it rather pretty.
@Alan Burke
25 down votes from people who have no idea what they are talking about...
To you down voters:
cmd ported many DOS commands for ease of use. It is most assuredly NOT a DOS prompt.
As for Powershell syntax, well, its based on .NET, so that might help you a bit with understanding why it is the way it is. And, Linux shell is no peach either... It comes down to what you are well versed in and spend time using more than anything else.
> And, Linux shell is no peach either...
Mr "It is most assuredly NOT a DOS prompt." pedant, I can be pedantic too:
There is no Linux shell.
Linux is a kernel.
There are executable programs that can be run by the Linux kernel that give you a shell, Bourne (sh), Korn (ksh), C shell (csh), Bourne-again (bash), tcsh, ash, and more.
You don't like the shell that has been installed by the Linux distribution that you are using? Install a different one. There is even Powershell for Linux if you prefer powershell syntax over the more common default shells used on Linux distributions.
> Go home, Stallman, you're drunk again.
Maybe you should read - and understand - the entire thread for context before embarrassing yourself?
Remember:
Better to remain silent and be thought a fool than to speak and to remove all doubt.- various unproved attributions including Abraham Lincoln and Mark Twain amongst others.
ETA: But I never take this advice myself, so yes I am a hypocrit.
If you mean this JCL, it's still very much alive.
I'm not sure what you mean by significant comments, but if you use JES3, the control statements begin with //* - the same characters that introduce a JCL comment - which means you can't include JCL comments that begin with any of the JES3 commands in your virtual card deck. You'll be pleased to know that JES3 is on its way out, though JCL seems here to stay indefinitely.
JES3 is now supported and enhanced by Phoenix Software.
Been over 20 years since I was near JCL so don't have any well formed memories, but it sounds more like it doesn't actually have "comments" but just ignores control statements that don't have a valid command ... so you could perhaps standardise on something like
//* COMMENT: actual comment text
<shrug>
I hate that comment structure on principle. I've seen some languages intended for education that take a real language, usually C, C++, or a derivative, and bolt on a compiler that does something based on comments. I won't name those languages to avoid drawing undeserved attention to that monstrosity. Every language must have at least one comment syntax that is guaranteed not to be treated as code and should be as clear as possible.
Yes, I was learning COBOL, which made sense. Also C and Unix with bourne shell, which also made sense.
Then they showed us how to run COBOL programs in JCL. Nothing makes sense there. That took my brain offline from learning COBOL.
Powershell reminds me a little of JCL, it makes a tad more sense, but hard to bludgeon your way forward like you can in *nix shells.
IMHO, Powershell's "ugly" comes from the fact that, on the surface, large portions of it look like "programming" as opposed to "scripting". But once you get down into the nitty-gritty, the facade falls away, and it's just scripting, or perhaps "scripting++", since MS did a pretty good job of pre-canning a lot of simple functionality for us (sorting, searching, reading/writing files, etc) that makes the old DOS prompt look absolutely spartan. I'm still doing about 40% batch files and 60% powershell - some things ARE still easier to do in a batch file, especially where there's an existing utility (Robocopy, icacls, etc) that does most of the heavy lifting.
Ah, but have you figured out how to do datastructures in a batch script?
It's sorta possible, but a horrible idea, and is based on the fact that "set" REALLY doesn't care what the variable name is. So:
set structure.array[12]=3
creates a variable called "structure.array[12]" and sets it to 3.
Buddy, I hate to tell you this, but COM was taken out back over a decade ago. Powershell can only work off .Net Assemblies, nearly all of which completely dispense with the archaic complexity of COM. There are a handful of interops specifically for speaking to legacy COM, but having to use it is incredibly rare in a modern system.
In comparison to UNIX that may be so (I demur about it being slow as I don't know). But Powershell for Windows is very good indeed, it's very useful.
I can imagine the people who demoted him sitting around nursing their right click muscle memory while drinking their decaffs... but but but he's making it more like UNIX. Isn't the whole point of Windows to have a window? Sip. More gluten-free biscuits, anyone?
dont you all recall the old saw " No good deed goes unpunished" ? Yes, I was mostly ksh for its speed over bash but in last job wrote production powershell scripts by reading manuals. I did love the *nix toolkit so much more after that, but one has to work with whatever toolkit is on hand.
> Isn't the whole point of Windows to have a window?
Something that always triggers me on any stripe of GUI (windows, X, whatever) are 'windows' that:
1) Can't be resized;
2) can't be moved;
3) prevent you from bringing to the foreground a window that is 'under' it that it 'spawned' from (modal? windows).
Each of those items seems to defy the whole point of using a 'windowing' GUI. The amount of times I've opened a 'config' window and think, "oh, what I need to configure depends on information that is on the window under it, but I can't see that information because I can't move/background this fsck'ing window that I need to put data into that is on the now-hidden window under it that I can no longer access".
I don't care if the developer thinks there's no point in being able to resize a window. It's a window, I should be able to resize it, maybe there's some use case they hadn't thought of, or the message it's to display is stupidly long and can't fit in the fixed-size window, whereas stretching it a bit might make the message intelligible? Barring any specific security considerations (maybe it's meant to hide some other information until some security check is passed), if it's a window, I should be able to move it, resize it, bring to the front another related window, grrr.
"... a window that is 'under' it that it 'spawned' from (modal? windows)"
This.
Windows the OS has forgotten how to do windows the GUI element. Windows that continuously steal focus as their parent program loads. Windows that don't respect the z-order and can't be sent to the back. Child dialogs that pop-under instead of -over. I recently wrote a script that includes a dialog "look for the password dialog (from other program) behind the other windows". Maybe MacOS and GNU-Linux have similar issues, but so far I haven't run across them.
I have a love/hate relationship with Powershell. When I script Windows in (four) other languages I tend to be very wordy, e.g. using long camel-case variable names, lots of small functions, etc. Yet somehow I find Powershell's wordiness too tedious. The saving grace is that sometimes Powershell can accomplish in one .NET pipeline what would take a fairly large VB Script (for example) to do the same, _and_ Powershell handles all the edge cases effortlessly, whereas in VB Script I usually end up with a comment "doesn't work as desired in case of xyz".
Agree BUT it's light years ahead of DOS batch and in certain areas, ahead of *nix scripting and even things like Python. Try working natively with JSON or XML files in DOS batch or *nix script without any extra utils, can't be done. Work with ZIP files without a ZIP util on hand, PoSH wil do that natively.
I find PoSH to be almost like SQL ( I was a DBA for 20 years ) , you must always be aware of the size and structure of what's coming down the pipe, if it's in the wrong format or too big, go back and keep the pipeline flow "lean, mean and clean".
I see so many PoSH noobs making the mistake of chucking bucket loads of crap down the PoSH pipe and then moaning it's complete rubbish, no you simply need to undertstand it better to make it dance.
The essence of the Unix approach is that the shell provides the control structures with very few builtins. All the heavy lifting is done by other programs; that puts them all on an equal footing, including any you might care to provide yourself.
I am very aware test has a string equality operator. I used numbers and numeric comparison operators here because I was illustrating the similarities between Bourne shell syntax and PowerShell, as well as the "ugliness" they both share. What emfiliane said is correct.
And what I was illustrating here was not specifically targeted at Bash—hence why I specified "Bourne shell" as I did. Following UNIX/POSIX nomenclature, Bourne shell does not include any built-in comparison operators (other than not operator !) and relies fully on the return value of programs, such as test. Unless you want to compile your own program to do what test already does or forego all of its functionality, there is simply no other way.
If you really want to be pedantic, it's POSIX syntax, and not explicitly Bourne shell syntax. Doesn't change the point.
You'd think equals would be =
Nope. I'd expect it to be an assignment.
Greater than >
Nope, I'd expect it to be a redirection of output.
The first is a universal issue in languages, differentiating between an equality test and an assignment. The latter isn't universal but it becomes an issue in a language that has to deal with redirecting data flows.
Yeah, there are a bunch of thinks in Powershell that seem weird like that. But there seems to have been a guiding principle behind it. Try first to resolve ambiguities, where conflicts exist, go with solutions that have been used in other languages/shells, etc.
I feel like it's not worse than perl and onboards WAY more stuff than the stock *nix shell (unless you include stuff from Awk and Sed, which are NOT par of the shell or shell scripts but can be called from them)
The way you work with stuff that deals with multiple objects in Powershell never sat comforatably with me. I still have to fiddle with the syntax whenever I doing something like a directory update or bulk user import. Too many things change from working with single records when you wouldn't always expect them too. Like figuring out which switches work outside or inside the ForEach, and which things you can set without one.
One of my biggest gripes in PS is trying to write code that can handle single objects or arrays being passed to it. It's the cmdlet/module authors' faults for not always sending one or the other, and there are cmdlets in the standard library that do it. Thankfully it is easy to resolve, but if you don't know what might be sending what before writing something, it can be very painful to debug later.
I suspect you don’t do much shell programming. Consider this bash snippet:
X=009
test $X = 9
... should that return true or false? It returns false, because '=' compares text. There’s a difference between lexical comparison (characters must all match) and value compare (parse to numeric, then numeric results must match), and numeric comparison is what -eq, -le, -gt and company do on the unix `test` command ([ is an alias for test, chosen to make shell-scripts a little more readable).
Powershell is similar, but you first need to know that PS is a typed runtime (like Python). The equivalent code:
set X 009
if ( $X -eq 9 ) { echo "true" }
will report true, because X is a number. Change that initial assignment to be a string, and the comparison now fails.
set X "009"
if ( $X -eq 9 ) { echo "true" }
If you want to force integer comparison, you can cast the operand:
set X "009"
if ( [int]$X -eq 9 ) { echo "true" }
When it first came out, I would have agreed with you. In truth I avoided it for years because "cmd just worked" and "the syntax sucks" and "it makes no sense why they're doing this" and "it's slow as hell".
But then the versions continued to roll out, more modules got developed, the infrastructure got better, and speeds improved greatly. And now we have the largely open-source and multi-platform .NET Core and PowerShell Core, with perfectly acceptable performance and a bevy of useful features. Being able to easily script against .NET Framework/Core objects (or just straight up write in CLR languages and load them at runtime) is such a huge boon, especially when Windows is so tightly integrated with it. There essentially isn't anything you can't do with PowerShell on modern Windows, and it far outshines the capabilities and cruddy syntax of cmd.
Anyway, if you want to talk about bad syntax, let's honestly and objectively take a look at Bash, or really Bourne/POSIX shell in general, and all their ilk. You mean to tell me x="hello world"; echo "${var%world}" is self-evident without already knowing what it means? Or the fact that you can't put spaces around the = when assigning a variable, which has tripped up every newbie? Or the other hundred non-trivial hurdles you have to work around to make a good script? The grass is not always greener on the other side. Even in Windows-land, ask any veteran sysadmin and they will tell you every which way cmd syntax sucks, and how inflexible and error-prone it is; it even shares some of the problems that Bourne shell does, like assigning variables.
Fact of the matter is PowerShell is a hell of a lot more expressive than its competitors, even if the syntax is still a little wonky after all its revisions. I'd take it over cmd any day, and if I didn't know anything about *nix shell and weren't already used to it, I would probably take it on Linux too.
Exactly this. As somebody who had used CMD for years, I didn't take to PoSH at first when Exchange 2007 came out.
However, once you get to grips with it, see how it treats everything as an object and follow some best practice guidelines (don't use aliases in scripts, strongly type all your variables, etc) it lets you do powerful stuff at the prompt and build very readable scripts than do pretty much anything with the system.
Something that in most other shells will take multiple lines and need you to parse the output of one command to feed into another becomes a simple one liner where you can just pipe one CMDLet into another.
Some CMDLets can be wordy, but many have aliases and tab completion makes their length a non issue anyway. When you use the full CMDLet names in script it makes them very readable.
Always remember: Filter left, format right!
I've never really used Windows for anything serious (my history is RSX->VMS->Linux, when not working on embedded systems) but I am impressed with Powershell for its ability to work with objects and collections as basic building blocks.
The ability to pipe around objects, instead of just character streams, along with primitives to allow constructs like "for each" and "case" switching based on class in a standardised way would be very useful improvements to bash.
..plus you can call into .NET assemblies. We've used it to knock up test harnesses and to write simple utilities to support our .NET applications. Sometimes it's quicker than writing yet another .NET application.
There are times it can thwart though. At a recent meeting we got stuck trying to get the value of a variable passed to an external application. We could echo it to the screen but couldn't figure out how to get it expanded in a command line. It being the end of the day was probably a factor in that but it's a pretty trivial thing to have defeated half a dozen software developers.
At work I use it to set desktop background color by embedding C# directly in the script.
Add-Type @'
using System;
using System.Runtime.InteropServices;
namespace BGInfo {
public class DesktopColor {
[DllImport("user32.dll", SetLastError=true)]
private static extern bool SetSysColors(int cElements, int[] lpaElements, int[] lpaRgbValues);
private static readonly int[] elements = {1}; //COLOR_DESKTOP
private static readonly int[] colors = {3873552}; //[System.Drawing.ColorTranslator]::ToWin32([System.Drawing.Color]::FromArgb(0, 16, 27, 59))
public static void Update() {
SetSysColors(elements.Length, elements, colors);
}
}
}
'@
[BGInfo.DesktopColor]::Update()
> to allow constructs like "for each"
Actually, this is shell's behaviour for "for": it just iterates thru the defined list.
You can create a numeric progression list via shell expansion if you want the original "for", but I don't think I've ever needed to do that for shell tasks.
"It's clumsy, slow, and with an ugly syntax."
It's all of that with inconsistent switches from command to command and version to version.
It also allows MS to stop developing GUI. Why right click and select an option when you can type a 400+ character PS command that can bork your domain instantly.
There is STILL no admin interface for Microsoft Bookings. It has been years, and STILL the only way to get access to someone's Bookings account is to manually add yourself with Exchange cmdlets. It's absolutely infuriating.
That aside, you should try PS Core. It cleans up a lot of the nonsense since it is essentially a separate product to mainline Windows-bundled PowerShell based on the .NET Framework. Later versions of Windows will likely include it by default once they get feature parity.
Several years ago I was writing software that required me to test against several enterprise backup packages. One of them had a UI that appeared to have been generated by parsing the output of the command line help for tar. Even down to some options effectively being duplicated.
I can't remember which one it was now. Like most of its ilk it was complicated and unwieldy to use.
PowerShell is only slow if you do things that make it slow. Yes, the pipeline is convenient but over use or inappropriate use of the pipeline will cause serious performance issues.
Other performance issues are not really PowerShell but the Windows services you are interacting with. i.e. Active Directory, Exchange, SQL server etc. Unfortunately these services can only be interacted with using Windows PowerShell, which is considerably slower than PowerShell Core.
When on earth will they come up with an equivalent of du?
full file system and you want to find the culprit in *nix
ls /some/dir | while read line
do
du -sh $line
done
I once found the code in powershell but it was so ugly I couldn't deal with it. It is good to have powercli on linux though so I can take snapshots etc. So, on balance I suppose it is a good thing.
The brevity of *nix is because all the commands were abbreviated out of necessity. The real star here is du/POSIX and not really Bash—just imagine what you'd have to do if du didn't exist!
Looking at the example, it's actually not correct. Fixing it you get the below output. (Unfortunately pre and code tags are being horribly butchered by our vulture overlords, sorry.)
PS C:\> Get-ChildItem C:\Users\me | ForEach-Object { Echo $_.Name ; $_ | Get-ChildItem -Recurse | measure-object -property Length -sum }
...
Desktop
Count : 63
Average :
Sum : 10194386
Maximum :
Minimum :
Property : Length
...
Downloads
Count : 26
Average :
Sum : 429328707
Maximum :
Minimum :
Property : Length
...
You're wondering what the syntax is about. We can break it down.
Get-ChildItem C:\Users\me |
Pipe in all children of your user folder. In PowerShell, all pieces of data are .NET objects, and every item returned by Get-ChildItem is fully formed. This is unlike other scripting languages that might return a string for the filename (e.g. Bash). This gives you a lot of flexibility.
ForEach-Object {
Here we iterate over the objects sent thru the pipe. This is similar to piping to read in *nix shell, but over objects instead of strings.
Echo $_.Name ;
This writes the item name to output; echo is an alias for Write-Output. (And its use tells me that the OP may not be very well versed in PS...)
$_ | Get-ChildItem -Recurse |
This is my change. Here we are sending the current object in the loop (in PS it's $_ for ForEach-Object) into Get-ChildItem. OP's example used . which used the current directory. We are using a pipe here instead of -InputObject or using -Path $_.FullName because it's shorter and should be faster.
Aside about loops: You can specify the variable if you use the foreach statement, but you can't use statements (easily) in pipes. ForEach-Object is a "cmdlet" and is able to process pipe input and send output, so that's why it's used here. You can also use -PipelineVariable xyz if the thing you are piping from is a cmdlet, and this will provide the variable xyz to the next scope in the pipe.
measure-object -property Length -sum
This consumes every object sent down the pipe, reads each Length value, which is in this case the file's size and provides a sum.
...But this example also isn't very good. It looks nothing like du output. We can make some changes to better emulate du and make it more "PowerShell"-y.
PS C:\>gci C:\Users\me -pv x|%{$_|gci -r -ea 4|measure Length -s -ea 4|select Sum,@{l='Filename';e={$x.Name}}}|sort Sum -d
Sum Filename
--- --------
429328707 Downloads
10194386 Desktop
2265 Searches
I tried to make it as compact as possible, and the output looks good; here is what it would look like if el Reg didn't murder it. Funny enough, this result from SO that I looked up afterwards does essentially the same thing, though I am making use of some newer language constructs (like -PipelineVariable via the -pv alias). If you are curious I can explain this one too, but it will take more time. It also is not truly faithful to the du experience, as it only shows the toplevel children including files, and does not give a grand total for the toplevel directory. Modified to do that, you would get something like this:
$x='C:\Users\me\Downloads';(gci $x -ad -r -fo -ea 4)+(gi $x)|%{$d=$_;$_|gci -r -fo -ea 4|measure Length -s|select Sum,@{l='Filename';e={$d.Name}}}|sort Sum -d
Sum Filename
--- --------
429329118 Downloads
288174446 folder 2
7952775 folder1
4964601 test
I know it looks esoteric as hell, but keep in mind I am trying to keep it short, which means using all the alises and shortcuts I can. I also must stress, we are essentially re-implementing du here, and that's why it looks so much more verbose. If du or an equivalent existed in PowerShell, it would be as easy as:
du | sort
which is no more verbose than in *nix. But as far as I can see there is no equivalent.
If you wanted to have an experience like that, you could take the snippet I wrote above and put it in a function/cmdlet in your PS profile, which is the PS equivalent to Bash profiles. Though, I would honestly recommend to not use it, since it's not optimized at all, and you are relying on whatever PS implementation you're using to properly handle all the duplicate objects :)
Good writeup.
I create functions for a lot of "foreign" commands and other useful stuff in profiles.
I put them in a module that I import in the "all users all hosts" profile on all the domain machines in our organization so I have them available on any machine. Only gets annoying when I use external machines that don't have the module and I have forgotten that a command I use all the time isn't available.
"Excellent example thank you. The brevity and elegance of Bash shines."
No, it doesn't. What shines in the bash example is the power of the du command. Delete that from /bin and try making bash do it for you. The result will be a lot longer and uglier than the PS commands written above.
There is also an alternative in PS: get the source for du, compile it, and put it on your path. You can use the one that Git for Windows has. Cygwin probably has a usable one too. Then all you have to do is pipe its output to a sorter of your choice. The thing that gives you all the power, clarity, and brevity is a platform-independent executable designed for the task. Bash does not deserve the credit for that.
The bash solution becomes ugly very quickly once your needs diverge from "results sorted by directory size". The PowerShell version, on the other hand, is trivial to adapt to sorting by any attribute of the system.
You can also trivially adapt the PS version to give you sizes, sorted by most-recently modified directories, or excluding directories that have not changed since a given date. Try that in a bash one-liner if you really want to learn the darker corners of bash (but really, don’t do it: complex functions belong in scripts, not one-line alias macros)
Lest I be accused of fanboyism, I should mention that I don’t use PS very much: I overwhelmingly write scripts in bash (or more accurately, the subset that’s approximates the original Bourne Shell - a habit formed from writing for embedded systems using dash and other lightweight shells). But I’m not some kind of idiotic zealot who thinks that just because something is from Microsoft, it’s inferior to whatever came from Unix. The reason I don’t use PS because it’s not well supported on Linux, where I do most of my scripting; and on Windows, its default commands are all different to what I know from Unix.
But if you’ve ever had to parse the crap emitted by linux tools like ip, you'd wish that Linux had something like PowerShell’s object-stream approach to pipelines.
Making the most common Linux tools produce key-value output (even if it has to be in a lousy format like JSON) would be a start, but that requires cross-project collaboration, which is something the Linux world has proven to be very bad at.
That lists each subdirectory, but doesn't total the size of each of those directories properly. I suspect it's giving the full disk usage of c:\some\folder because the totals are the same for each child directory.
cd I know it's behaving in your example, but here's my output:
PS C:\Users> Get-ChildItem C:\Users | ForEach-Object { Echo $_.Name ; Get-ChildItem -Recurse . | measure-object -property Length -sum }
apeery
Count : 1946
Average :
Sum : 38742310694
Maximum :
Minimum :
Property : Length
defaultuser0
Count : 1946
Average :
Sum : 38742310694
Maximum :
Minimum :
Property : Length
fred
Count : 1946
Average :
Sum : 38742310694
Maximum :
Minimum :
Property : Length
Public
Count : 1946
Average :
Sum : 38742310694
Maximum :
Minimum :
Property : Length
Directory: C:\Users
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 08/02/2022 09:46 apeery
d----- 04/05/2021 16:15 defaultuser0
d----- 03/05/2022 12:56 fred
d-r--- 06/05/2021 00:04 Public
nix users will only see cmdlet names as an unnecessary waste of space, because they live in a world where all the commands are 2-3 letters that everyone understands because they've seen them for decades. Might as well use aliases for the sake of comparison:
gci | % {@{ $_.name = (gci $_ -R | Measure Length -Sum).sum}} | sort [Keys|Values]
You can sort by Keys (filename) or values (filesize). It's not bad for a native implementation without a dedicated standalone like du. If you wanted to make it really pretty and do it properly then you could treat yourself to a dozen kilobytes of code in your profile to write a proper function. Depending on the skill of the implementation, the flexibility and intuition of it would quickly outstrip what du offers.
Whilst you've shown how terse UNIX like OSes are, I would argue that none of your example actually shell, apart from constructing the pipeline.
Du is a separate program. Sort is a separate program. All the shell has done (and with this example it could be pretty much any shell) is spawned the du and sort, and connected them with a pipe. Even the pipe itself is not a feature of the shell, but of the underlying OS.
Too many people cannot differentiate what is actually part of the shell, and what is separate programs. That is one of the strengths of the UNIX way, but it can lead to lazy thinking by people who don't fully understand the thinking.
I once taught an IBM course, (IX22 maybe? It's a long time ago) called "Advanced Shell Programming". In it, the material included tools like awk and sed (but not Perl, as that was yet to be mainstream), but I was at pains to point out when I was teaching that these were really not part of the shell. I made sure that the students understood the difference. I actually set an exercise for them to really perform a task completely in the shell. I can't remember exactly what it was now, but it was much easier using external programs, but still possible in the shell.
I did manage to slip in some examples of ksh co-processes, however, at least one of which was actually useful!
"When on earth will they come up with an equivalent of du?"
I was just looking at this last week to find a way to log directory sizes on the file server. There is a du utility somewhere, maybe from SysInternals. But it turns out, to get the disk usage of really large directories, the "fastest" way to do it in Powershell is to use Robocopy (with the /L switch) and parse the output. Crazy as hell, yeah, but true. Takes like 8 lines of PS code and bazinga! Robocopy must have super-magical Jedi code in it because it hands-down beat the shit out of every other method I tried, by a large margin.
"super-magical Jedi code"
Old fashioned Win32 API, instead of modern .NET. But I suspect the biggest difference is that to code in Win32, you had to know _everything_. To code in .NET, you can get by without knowing much. Powershell is the apotheosis of .NET, more so than C#.
I figure it's more than just Win32 vs .Net, since I assume that SysInternal's "du" command is Win32 as well. But Robocopy thrashed it and usually only took a mere fraction as long to go through a large 300,000+ file directory (seems like I recall Robocopy took 9 seconds, du took around a minute). My un-wizardly guess is that Robocopy puts its fingers down into some low-level NTFS stuff directly, or as directly as is possible under an NT kernel.
You can do job control, but it's nowhere near as clean as with *nix shells, i.e. just put & at the end. Here is an older but still relevant high level discussion, and here is the official documentation. Once you get used to it it's fine, but it's still a bit more to type and manage.
At least it's better than cmd, which has no such functionality.
I used PoshRSJob for a script a couple of years ago, it allows "parallel" processing for stuff like pinging an entire subnet (that's what I'm using it for anyways...). I didn't dive into it as a learning experience, just figured out what I needed to do for what I was doing and moved on. In my case, it made a helluva difference in how long the script took.
One of the interesting parts of the thread was the total toxic culture due to a particular VP. It explains a lot and MS at the time, and I wonder whether the culture of stack ranking was part of it?
Certainly he seems to have a VP who was scared in upsetting his bosses, and was not willing to fight for their team. Basically a culture where innovation was frowned upon and discussion was stamped our.
It pretty well explains a lot of MS products at the time
How Microsoft operates internally reminds me of how Trump operates. If you are not making Windows look good then you are Fake News( bad for Microsoft and bad for Windows ). No doubt PS acted too much like the *nix commandline even if more in intent than execution. Linux is bad because it is not Windows and anything which validates something other than Windows makes Windows look bad. Trumpanze thinking and this thinking has been instilled in Microsoft management ever since their split from IBM.
Your use of the present tense is odd in that post, given Microsoft’s current championing of PowerShell—and, for that matter, Linux—on Windows today. This is not the 1990s anymore.
And Microsoft never had any relationship with IBM they could “split” from apart from being a vendor of DOS, and a development partner in OS/2 - both in the 1980s: anyone managing then retired long ago.
The rot in the 1990s was what happens to any dominant player in a market: gaining share becomes more difficult, so management decides instead to rent seek, and adopt defensive positions to block competition (we’re seeing this with Apple on mobile). Of course, these tactics are contrary to the needs of customers, and can sow a long-lasting poison that damages the chances of any genuinely good product that comes from the company later. As an example, Windows Phone was the most techically advanced mobile SDK, with amazing low-resource performance, and I believe that it would have been a success had it not come from Microsoft, with all the baggage and industry distrust that that entailed...
Microsoft, like other successful companies, also attracted the bullshitters. I worked for Apple in the 1990s, and we used to say that the only good thing about working for a dying company (which it was then) was that the kind of MBA-but-no-intellect manager-class tended to avoid us when choosing a place to inflict themselves upon. Instead they flocked to Oracle, Netscape (heh), Microsoft and Sun, who were all on the up, and thus offer a low-risk environment for their inept ideas. (Not to say we didn’t have home-grown assholes, but nobody tried to bring in morale-destroying “new ways of working”)
Windows champions PowerShell today, but they are also always looking for GUI options to supersede it. Modern PowerShell is like the fallback for the relatively small power user base. The native Windows version hasn't been touched since 2015. Windows Server 2022 won't commit to PS Core either, so it will be at least 10 years if not more shipping a version with some noticeable performance issues. I feel it's the best framework for a shell experience out there by a long shot, yet its potential could be pushed so much more than being a sideshow.
But reading the comments here reminds me that it's difficult to engage new audiences. PS's potential makes it most ideal as a shell for developers and programmers who can take advantage of coding; meanwhile, all these developers and programmers spent their freshman year in college in Bash and have stayed there for the past however many decades. To them, the mystifying moment you first try to tackle a nix commandline with arbitrary 2-3 letter commands, opaque single-character parameters, and inconsistent syntaxes unifying the built-in functionalities has completely vanished from their memories. The equivalent proficiency in PowerShell would take half the time or less, but that could still mean several months of consistent use.
Then, among the Windows userbase, all the Windows admins are always looking for "The right tool for the job" -- basically an executable or interface that does everything for them with a click or single command. I can't tell you how many I have come across that can barely put a script together. And so Windows keeps investing in the handholding measures as there is little incentive to push the potential of the language.
PowerShell is unfortunately awkwardly positioned in Windows.
Yes, it's what you do admin things in on Windows, but Powershell was such a lost opportunity. It was obviously designed by someone who'd never used *nix and therefore made all the same mistakes as its shells but learned nothing from some of the great design decisions. In an ideal world Powershell would have been an object oriented tcsh (or zsh, bash, whatever your oshi is), like C# improved on everything Java, but instead it's just another clumsy mishmash of inconsistent design and baffling omissions. It's better than DOS BAT, I'll give it that.
It was designed in the era where Ballmer ran Microsoft and Linux was a threat to the bottom line not a universal fact of IT life & included Windows feature.
Stuff like Ansible wasn't really a big thing back then either, and if it was see-above on mid/early 2010s MS and nix-y tools....
Yes, they should have gone with a Bash derivative and exploited the existing knowledge base..... But the same argument could be made for NT way back when (NT being mutant VMS because the Alpha and PowerPC were going to give Intel a run for their money (oops))....
"Fire and brimstone coming down from the skies! Rivers and seas boiling! Forty years of darkness, earthquakes, volcanoes! The dead rising from the grave! Human sacrifice, dogs and cats living together... mass hysteria!" -- The Ghostbusters explain why not to buy or use any Microsoft products. (an ASR sig).
I'd go more with, someone decided to create a language that would (eventually) do everything you could possibly ever want to do with a system or database by adding 'modules' and roll it into a big giant mess that makes PERL look good. This is similar to what IBM did when it went from OCL on the 34/36 to QCL and then onto compiling CL for 'performance' and now I can have input forms on my CL! Every time I've tried to do something with powershell I've had to get a module, or something, and then everything is an object, so often the result you get is not what you expect, or requires further parsing or... It's just very darn inconsistent from function to function, and then the function you found that does what you want is only for Azure, not a domain controller, and ...
Sorry, but I'm not overly impressed with powershell to this day. dumping write-hosts's to see things in loops often fail to reveal actual object content that breaks somewhere else, blah, blah. Working with objects is great as long as you have a thorough understanding of each and every object you use. You are a maze of twisty little objects, all different.
I think shells and shell scripting should really be GLUE logic for weaving things together. If you want to get serious write some real code, in a language designed to accomplish the task, and use your shell to weave it all together.
And I'm happy to help tar and feather the idiot that decided names should be quoted and escaped by default in a directory listing on modern unix breaking scripts. (ls -1 | ...). The minute you make a 'shell' that is all things for all people, what you end up with is a 'thing' that is a necessary evil for a lot of people.
Of course opinions are like assho...
I think much of the criticism of Powershell comes from either:
1. People who have never used it "because its Microsoft"
2. People who have used it a bit and become disillusioned as it is unlike other shells they have used.
I was not keen on it at first, but after having a few "Aha!" moments, I now could not do my job without it.
There are a few simple tricks that work wonders (like using get-member to fully understand all the properties and methods that belong to an object) and major performance tweaks like filter left, format right and not using += on large arrays.
Best advice I can offer is to actually read some of the various primers and best practice guides out there (both official and unofficial). They will give you some key understandings that you probably won't get by just diving in and playing around.
Being able to grab a collection of objects and cycle through them all with a foreach one liner lets me get results in seconds that using older methods could have taken hours.
Other methods would normally mean bending the output of one command into the input the next one needs. With Powershell, just send it all down the pipeline, then worry about formatting the output at the end.
I've upvoted you for your comments about quoted filenames in ls, but I think you'll find that if you pipe the output from ls into something else, it doesn't quote the file names at all (try ls | cat).
This means that it is unlikely to break scripts.
You can also set an environment variable QUOTING_STYLE=literal to remove the quotes,
But like you, I can't stand having the quotes, And I also can't stand the arrogance of the developers who change it, and apparently ignored all of the complaints.
I'm interested in hearing which modern UNIX has adopted this. I guess if you're using GNU coreutils on a Sun box you may pick this up (but I wonder whether the native Solaris 'ls' does it), but I don't believe AIX has implemented this. And there aren't many other UNIXes around anymore.
I've been using Unix for more than 30 years, and at first I had no idea what this comment and its parent was talking about. So I googled, and discovered something new. Thanks to you both! The gist is:
https://www.gnu.org/software/coreutils/quotes.html
which describes how GNU broke ls in 2016, apparently in order to make it easier to cut-and-paste with a mouse.
I'm especially interested that it has apparently been a thing for eight years, and even though I use Linux and the gnu utilities quite often, they are not my "primary" unix environment, so "hmm, that's odd" hadn't percolated to the level of working out what was wrong, until now. As explained: the decoration is only applied if stdout is the terminal, not a pipe.
Regarding the comment "aren't many other UNIXes around anymore": well, there's still macOS and the BSDs, which is where I do most of my command-line work.
Not spotted my posts before, have you.
When I talk about UNIXtm, I'm talking about Genetic UNIXes, i.e. ones that were licensed and developed from AT&/Bell Labs., or UNIX that has been through the verification process from The Open Group.
MacOS does not use a UNIX kernel. It uses a kernel derived from the Mach kernel, with the BSD toolset grafted on top. One of the versions a while back was certified as a UNIX, but Apple did not keep up with the process. So yes, macOS could be a UNIX, but in my purist miind, it's only UNIX-like.
The various BSDs are derived from an archaic version of UNIX that not only diverged from mainstream UNIX back in the 1970's, but legally does not contain any UNIX code not inherited from UNIX Edition 7 (and proved in a famous case between AT&T and the Regents of the University of California).
There has been no BSD UNIX-like OS that has received UNIX branding.
I admit that *BSD* OSs are very much UNIX like, having been using UNIX since 1978, and having used BSD since when it was shipped as an add-on tape for a Bell Labs. But there is no way it can be legally called UNIXtm.
So, the last UNIXes standing are AIX, which is sort of still being developed, and Solaris and HPUX, both which are not (no new hardware driving development). Everything else has fallen.
No.
It's more like 'what if we built a command line interface around a hodgepodge of VB and JavaScript'....
It's A-LOT more functional than cmd or the old VBscript, but it's got no connection to the (much more established) UNIX command line, as it's a product of early-2010s Ballmer-run MS not the 'we make our money in the cloud & bundle a Linux environment with Windows' 2020s version....
One more thing... It's truly amazing for managing VMWare hosts.... As opposed to pointy-mc-clicky in a web browser...
New MS released it for Linux so you can actually have a Windows free world, and still use pwsh for managing ESXi virtual-appliances (which use photon Linux as their base OS)....
Last job I did after 50 years of being involved in most things IT was to write some PS scripts to read a MySQL database via ODBC for people holding certain posts and create as needed accounts in the online Active Directory and apply SharePoint folder permissions depending on the post. Email the new user and the sysadmin, also remove persons or change perms as the posts changed.
More recently I was asked to change the data source to a REST API returning JSON when the database moved off prem. Easy and quick.
Try doing that in bash or cmd.exe.
It was about 30 lines of functional code by the time it was nice and maintainable for a non programmer sysadmin.
I could have done it in:
PERL - Ugh. Very powerful and I loved it when we were both young, but sadly the romance faded.
.Net 300 lines
c# 450 lines
PYTHON never did get the hang of those white spaces and tabs and far to prone to getting messed up by said sysadmins.
"...create as needed accounts in the online Active Directory ... Try doing that in bash or cmd.exe."
dsquery / dsget / dsadd / dsmod would do that in cmd.exe, probably even easier than powershell. Funny though, they pipeline objects just like powershell does.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc732952(v=ws.11)
I grant that sending an email is not so easy in cmd.exe. And for SharePoint, powershell is The Way.
It pays to keep in mind that the "traditional" unix tools are all about flat/regular files embedded in a hierarchial file system. They don't do things like JSON queries well, but that's OK: there wasn't any JSON when they were pulled together. *
Today there's jq, and we can get on with pulling information out of JSON files in simple one-liners as the gods of REST intended.
(*): Call me old-fashoined and a slave to my favourite tools, but I've never met a JSON file that I prefer to the obvious alternative collection of flat multi-column files. Still, it's all the rage, and there's likely no going back. "Self-documenting", they say, as though that was a virtue.
You can do some awesome stuff with PowerShell, but sometimes making it do that awesome stuff is an utter nightmare. What a cmdlet returns isn't always documented well, or at all. What repository the cmdlet is in and what permissions are required, etc. etc. PowerShell ISE on Windows is a tremendous help for all that.
But then you get it all working and the power to automate some very tedious or complex tasks is fantastic.
The simple can sometimes be brutally cumbersome, and the complex can be a breeze with it.
I was on the same team as Snover when he came up with the idea of PS. The really important part was the decision higher up to wrap all of the Windows API in .Net classes. That allowed a .Net utility like PS to be able to access all of the .Net class library. Lots of us, myself included, saw the need to have a consistent and accessible way to interact with Windows. I programmed for decades in C and C++ and it is really difficult to get code correct in those languages. Memory leaks, wild pointers, buffer overflows, oh the joy goes on!
The MS review process at the time was notoriously fickle with managers forced to assign review scores on a curve. I hadn't heard that he was demoted but he wouldn't have wanted to broadcast that kind of thing. As the saying goes "The beatings will continue until morale improves!"
One of the original PS designers wrote a book on the design process. He went into great depth on the discussions and decisions about the design choices that were made. Unfortunately I'm forgetting his name and the name of the book. Perhaps someone can contribute that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
