Anyone else tries to keep their file names in an "eight-point-three" format anymore?
When MS went to 256.256 (98?), I just threw my hands up in surrender..
PowerShell is everywhere, it seems. Not just in Windows Server, SharePoint, SQL Server, Exchange, Lync and Azure cloud, but it’s in third-party software, too. Take VMWare PowerCLI – that’s an extension of PowerShell. With many in the Windows world chewing on this fat PowerShell server software sandwich it’s easy to take …
As someone else mentioned, MS seems finally to have approached the state of 1975 Unix (or maybe 1983, with Korn shell). I have to add ZCPR for Z80 based 8 bit systems. If I recall correctly, it had a passable imitation of the Unix shell, common utilities, and I think pipes, subject to the limitations of an 8 bit CPU, 64K memory, and lack of multitasking. I saw nothing better until I started playing with Minix 1 as part of a grad school class, and then found a used copy of IBM Xenix 1.0 at an amateur radio flea market. The last saved me a lot of time when learning to handle C pointers and references without the need to reboot at every mistake.
I'll grant Powershell has a certain amount of advantages if you're running 2008R2/Windows 7 or later with the certainty it's built in, or when needing to perform administration tasks closely coupled with some Microsoft products. However, for other instances, why would I bother using something extremely platform specific when there's the opportunity to use Python or a wealth of Unix derived utilities to solve the problem, and not tie my skills to a particular OS?
I've done some scripting, read the documentation and some of it is extremely well designed and rather neat. For most purposes, though, I'd still rather use Cygwin, Python or C++.
The piping in DOS was also a nasty kludge; it did not support true pipes. It would write the ENTIRE stdout from the first command into a temporary file, then only when this was completely written out, open the temp file and feed it into the standard input of the next command. I.e.,
dir | more
would write the entire result of "dir" into a temp file, then open the temp file and run it into "more".
I assume (hope) that powershell uses actual pipes to implement pipes.
> Are you SURE it went to a temp file and not RAM? I know at least once I overloaded a pipe which you wouldn't expect to happen with a temp file given enough free space.
Yes. If it went to RAM during the first program then when it tried to load the 2nd program it may not fit - or more likely would overwrite the data.
A compromise between a useful shell and learning something which only has value on windows, a platform of declining relevance to the world of servers, is bash. Git for windows comes with bash and it's nice to have one common shell as I move across os x, linux and windows. powershell looks very interesting but I have not been able to justify learning it yet. For more advanced admin python on windows works well and once again there is not a new learning curve. I wonder if the new Microsoft would have done something as idiosyncratic as powershell.
Maybe this has since been resolved, but I remember being underwhelmed by my first major outing with Powershell.
The task was to replace some aging VB scripts that communicated with Exchange Server 2003 via CDO. The exchange server was being replaced with Exchange 2010 which of course no longer supported CDO in favour of Exchange Web Services (EWS).
So we selected Powershell to use the EWS API. We ended up with a custom C# snippet in the Powershell script that implemented an accept-all certificate handler to work around the connection errors we were experiencing between the script and Exchange (as advised by MSDN and MS blogs).
Oh and of course make sure for the love of god that you selected the right number of bits (32 versus 64) when you executed the PS script. And that you selected *exactly* the right version of the EWS API DLL to download and deploy, otherwise PS just threw an exception.
All this just to read certain subject lines from emails in an Inbox. Conclusion: Even in 2014 the tools felt like a poor beta.
(Oh yes, code signing PS scripts with the cmdlet. Sometimes it just wouldn't. But take the script + code signing cert to a similar workstation and then it worked. Weird!)
Yeah, just watch out for the icacls command - I wrote an all-in-one create-user script last year, and after an hour or so of aggravation, I gave up trying to escape the colons and parenthesis and just stuck it in a batch file that I called from the create-user script. There are "native" ACL commands in Powershell that are powerful, but they are even uglier than a batch file and take too much coding - or at least it seemed like a lot of code just to replicate the functionality of a single line call to
"icacls %2 /grant %1:(oi)(ci)(M,DC)"
If it isn't making the job easier, why use it?
Biting the hand that feeds IT © 1998–2019