101–110 of 130 posts
I've found this by trial-and-error - while I was editing a batch file that was executing, it would suddenly error out with meaningless info, sometimes it'll print out the things I've just added to it.
Just use a decent language like Ruby instead.
Could be great to have a compiler js -> bash / batch
1. From UNIX point-of-view, not all has the luxury of bash, so seems to be quite limited to a certain modern platform? I found out ksh are more prevalent 2. I actually use UnxUtils in windows so I can has POSIX command option (and scripting). Performance-wise, never tested as not needed, all short command / simple script
Earlier quoted context omitted.
PS> Set-ExecutionPolicy Unrestricted It's the first line of just about every publicly-distributed script (including Chocolately, etc).
One of the reasons I'm still afraid to use Powershell - its just not succint enough for normal day to day operations.
PS cmdlets in generally are quite consistent: there is a [Verb]-[Noun] naming convention (eg, "Stop-Computer" above) and full tab completion, so if you forget the exact name of a cmdlet you can do Get-[tab] and cycle through every Get-* cmdlet that exists. Even command line switches tab complete, just type a hyphen and then you can tab-cycle through every command line switch that particular cmdlet supports. There's also Remote Powershell, which is like SSH but also built-in. I can sit in a Powershell window and connect to a Windows server anywhere just like SSH on Linux, or even compose a script block, assign it to a variable, then send it over the wire to be executed remotely (or to a group of machines in a foreach loop). It's pretty slick, and all this is built into the shell--no third-party tools required.
I'm not a big fan of MS, but I'm willing to give them kudos on the rare occasion that they build something nice. Powershell has it's quirks like anything, but it's a damn nice piece of engineering and a godsend to anyone who has to administer Windows boxes. Why anyone would continue with the anachronism of (essentially DOS) cmd.exe is beyond me.
Long ago I thought about writing something that compiles to batch files, if only to make complex logic a bit easier to write or make the process of thinking about every little syntactic idiosyncrasy less tedious. Since then I found PowerShell though, and the need of writing complex and sophisticated batch files isn't so much there anymore¹. Nice to see this compiler adopting some idioms that make it easier for workin…
The main issue with powershell is portability - no guarantee that someone's Windows box will have it installed or not. I recently wrote a batch script just to make sure it'd run on any Windows system rather than risk powershell. If it was always going to run in a controlled environment, I'd have written it in cygwin bash anyway.
Earlier quoted context omitted.
You have that guarantee starting with Windows 7. Version is one thing; some nice things are available only in v3+, but v2 is very usable already. Execution policy is another matter, but you can always supply a batch file with the PowerShell script containing powershell -ExecutionPolicy Bypass -NoProfile -File %~dp0.ps1 %* That's what I usually do, which is also helpful for colleagues who have no idea how to run a Pow…
I thought powershell had to be explicitly installed/enabled even in win7. I'm not going to walk a user through that when I can do what I want in batch (with more pain, but still less than ending up providing support...). My normal area is Linux though, and both powershell and batch make me appreciate bash so much more. Even those little things like being able to format arbitrary dates as you want...
Earlier quoted context omitted.
This eludes me but why care about the performance of a shell scripting language?
With PowerShell level of slowness it starts to matter. Even very basic commands seem to sometimes take many seconds to run. In the middle of intense workflow it becomes a problem.
Earlier quoted context omitted.
The main issue with powershell is portability - no guarantee that someone's Windows box will have it installed or not. I recently wrote a batch script just to make sure it'd run on any Windows system rather than risk powershell. If it was always going to run in a controlled environment, I'd have written it in cygwin bash anyway.
You have that guarantee starting with Windows 7. Version is one thing; some nice things are available only in v3+, but v2 is very usable already. Execution policy is another matter, but you can always supply a batch file with the PowerShell script containing powershell -ExecutionPolicy Bypass -NoProfile -File %~dp0.ps1 %* That's what I usually do, which is also helpful for colleagues who have no idea how to run a Pow…
I love me some Powershell. Wrote my first non-trivial PS script in early 2010 that was a major component to building something I would now call "Continuous deployment of Windows OS images."
But I still have way more lines of BAT in production than PS1 because the versioning is a nightmare. v2 was the first really usable release and it ran everywhere I cared about except for Windows PE. v3 got some nice enhancements and support for Windows PE, but dropped support for anything older than Windows 2008. v4 added some more but took away Windows 2008 R1.
If it were just that newer versions of Powershell offered new modules and cmdlets it wouldn't be such a big deal, but the syntax itself has been evolving. This is valid in PS v3+ but not in PS v1/2:
Get-Alias | ? Definition -eq Where-Object
Get-Alias | ? { $_.Definition -eq "Where-Object" }
There are plenty of sucky things about BAT files... But they are truly lowest-common-denominator on any Windows system, there aren't any syntactical landmines waiting to get you with different Windows versions since 2003, and for anything you want to do on Windows that you can do with Powershell you will certainly be able to find a command-line tool that lets you do the same thing with Batch.
I for one am disappointed that they didn't host this on a .it domain.