I'm not so sure about the utility of this in my case. I usually end up using python for scripts, with perhaps a one line batch file that runs it with some default arguments for convenience.
Yup, that's all we end up doing, but it would be nice to have something that combines both programming bliss with end product being just one Bash script that runs on every Linux distro.
I have to confess, that I'm also one of those guys. I usually anyway installing Python anyway. So using it all scripting is trivial. Even if Python is "heavy and slow", people seem to forget that Powershell is lot heavier and slower.
This implementation is not perfect, although it's interesting that it supports Windows. I personally don't care about that, but it brings the idea to create some sugary wrapper around Bash that allows you to use Bash v4 features such as associative arrays in Bash v3, and wrappers that allow functions to return arrays and other typical headaches.
My initial thought after seeing this is Windows support is interesting, but the real value is in making bash friendlier. Something that brings syntactic sugar to bash is welcome in my mind, as I always find myself putzing with Google to find solutions to even slightly non-trivial scripts.
Perhaps I should just master bash scripting once and for all (I know it's not that complex), but I generally find it unpleasant to do anything that requires control flow or traditional "programming language logic" in bash.
A simple way to bootstrap the compiler with the script itself would be especially nice. Basically, an embedded batsh compiler. Might be an interesting avenue for an enterprising person to look into.
Most of the time I find myself struggling with Bash, it's because a simple script has kept expanding in scope and I'm well into the sunk-cost fallacy in trying to fix "just that one last thing".
But unless you have a really specific environment, I'm pretty sure most modern servers probably have Python or Ruby or some other stack that can be a shell script available. If you're in Bash, it's because you were trying to do something quickly.
>> A simple way to bootstrap the compiler with the script itself would be especially nice. Basically, an embedded batsh compiler. Might be an interesting avenue for an enterprising person to look into.
This could be very easy. If this can't be rigged with simple shell scripting (in a reasonable way), then it could with straightforward changes to the compiler (such as outputting to standard output). If you don't mind doing somewhat silly things like writing out scripts as temp files, this could certainly be done now.
As I said in the other threads, the language is great, the performance has been abysmal in relation to batch (at least for me, having started with Powershell in its first release in Vista).
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.
Care to give examples? I know that the language isn't fast, but afaik nearly all shells are interpreted. There have been performance problems with break/continue in earlier versions as they were implemented using exceptions internally. But that doesn't really qualify as "basic commands", I guess. Cmdlets should be not much slower than running the equivalent C# code yourself.
Hmm, I can't seem to reproduce many such issues with this machine, except Get-Help the first time I tried it. I think it could be that the cmdlets are only slow on the first run (enough to leave me with a bad experience), or the SSD on my PC masks the problem. It's good to know that it's not always super slow.
If it's slow on the first run, then it might be loading a large interpreter from disk. If so, MS might have let the interpreter get a bit ungainly -- you might argue.
What could a shell possibly do so that a basic command would take many seconds?
Currently, "many seconds" is enough time to run an interpreter on the command, connect to a remote machine in Iceland, spin up a new virtual server there, send the command there to be executed, review the execution results for possible exceptions, run a malware scan, fetch the response back, execute the command again on your computer, translate the command and results to Klingon, send them to NSA for archiving, play a quick game of chess with another instance of the shell, and play a congratulatory tune.
Seriously, computers nowadays are fast enough to run a partial compile of your code at every single keystroke while you're writing it. It takes special effort to make a scripting language unusably slow - even an unoptimized interpreter that itself runs on a different interpreter should do just fine.
I use Powershell for many administrative tasks at work, and it can be annoying if querying data from a single machine takes 5+ minutes. Which it does sometimes.
Totally agree. Powershell is what you need to use on windows. It's been available on the default server install since 2008 R2. No need for batch scripts anymore.
This sounds like you're saying that it suits your needs, therefore we should take that as meaning it fits our needs. Unfortunately, things are not that simple.
I needed to do something and looked at using powershell, but in the end I couldn't just distribute it and have it work for whomever would be using my project. It needed to be signed or something. On the contrary, the bat script I wrote just worked and would just work for anyone who used the project.
Powershell is not a magical solution that suits everyone's needs. This kind of blanket statement helps no-one.
There's a config switch to allow execution of scripts. I agree it's a complete pain (literally falling at the first hurdle), but it is a one-time thing change.
I had mixed opinions of powershell when I tried my hand at it. The naming convention and documentation system were well designed, piping objects is an interesting concept, and IDE support was great for a terminal (step through debugger, intelligent auto complete). Despite this, there were numerous quirks and ugly spots that diminished the experience. I felt it was a missed opportunity. This was powershell 3, I can't speak for later versions
Thanks for this candid impression. I had some slight interest in learning PowerShell, but it looked like a little bit too high of a learning curve, given that I had other scripting languages I could use (including bash in Cygwin). Piped objects struck me as interesting when I read about it in a magazine, too, but somehow they aren't needed to perform all kinds of scripting in *nix, so I wonder if they might be more complex than the problem called for. I get the impression that PowerShell may suffer from having come from Microsoft -- a company with bottomless pockets to spend on developing software and probably little need to stop smallish system utilities from becoming ornate.
I beg to differ, and not only because I code-golf in PowerShell. Aliases and the ability to shorten arguments while they're unambiguous both are features that have no use for scripts, but are very handy for an interactive shell. I never type things like
Get-ChildItem -Path ~ -Recurse
if I can help it, instead it almost always is something like
ls ~ -r
I guess -Recurse only ever appears there if I hit [⇄] for parameter completion.
Sadly there are far too many people who only know bash and see straightforward conversions of VBScript into PowerShell and think the language sucks or is too verbose.
On the contrary, one of the first things I do on a Windows box is open up a powershell window. Especially on Win 8+, it's a lot easier to do "logoff" or "Stop-Computer -Force" or "Restart-Computer" than to try to navigate the mess of Metro to find the GUI menu options. Moving files around on the PS command line is much more efficient than using Explorer, just like bash/Terminal on the Ubuntu desktop. It's just a matter of getting used to it (and learning the different syntax from Unix shells).
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.
For simple use cases I still use batch files as the performance is much greater. Powershell feels too heavy when I just want to run a build with some parameters and a couple of other commands.
I think it's really interesting the way programmers will use phrases like, "it feels heavy", as a way to describe using programs that contain unused features. I'm guilty of the same. Powershell "feels heavy" because it is a lot more sophisticated than batch, you can do all sorts of cool things with WMI or use data structures, but in the end, what does programming in batch actually gain you? If performance is such a problem that you notice a performance penalty when switching between shells, something is seriously wrong.
But I'm guessing you don't really notice the performance difference, you just feel the weight of unused features.
The opposite effect is, IMO, how things like node.js gain in popularity - the environment "feels fast" and "feels simple" [for the simple use cases that are always at the start of things].
I can't think of a case where seamlessly having two different targets like this has worked - particularly if there's pressure to really support all of the features of both.
Unity 3d. Haxe. [1] GWT. [2] There are tons of cross-platform toolkits that do this for games; having something that does it for SHELL SCRIPTING seems trivial by comparison.
Yes it does happen that some features get neglected, but we're talking shell scripting here. They could hit the 80% use case and it would be totally useful.
These days, if I'm writing something in bash (or batch) it's often because there is nothing better available - like kicking off an installer, or some other wrapper / bootstrap script.
For those kinds of simple tasks, the overhead of fully understanding the nuances of bash _and_ bash is way more trouble than the inconvenience of having fewer features available. This is not for bat/sh lovers, it's for those who have to use bat/sh even if they'd rather not.
Having said that, I wouldn't use batsh myself until it does something sane with errors (at least the equivalent of `set -e` in bash).
I posted it here to start a discussion not as an endorsement as we have all kinds of sugary compilers - for JavaScript and other languages, but none of Bash. Cross-platform support would be nice and as others have pointed out, PowerShell really took over Batch especially when Microsoft took care of the slow loading issue. I personally would rather have an extension of Bash rather than a brand new language, but that's me. In fact, I've been thinking of a simple preprocessor that even combines a bunch of scripts into a single one for easier distribution.
Love the idea of writing bash in a higher, easier to read format, similar to CoffeeScript. Unfortunately Batsh is written in OCaml (the author addresses why he uses it though).
Only half-way; it doesn't stream the data, it waits for the first command to finish, saves the entire output, then starts the second command with output as input.
This is great for me. As part of my day job I am often stuck writing batch scripts (yes, in 2014) for clients that refuse to run powershell. Writing a simple batch script is usually not a problem, but it can be very encumbering as the complexity increases.
I want to agree, but my major gripe using the different incantantions of Powershell (and I have tried, I am Winboxen admin often in my job and tried it before any other co-worker on Vista, obviously the story has improved since) and the startup time and performance was abysmal.
In terms of performance for very basic scripts (silent software installs, 5-10 lines, registry patching, etc.), I see the performance chart as:
Batch > VBScript > Powershell
in terms of speed. I wish I had tried Jscript, because the ironic Javascript is taking over the world could have meant retro hipster superiority (and scary you could integrate JScript and VBScript into the same script by embedding them in XML type directives and using the WSF system). Now that was scarier than any of this.
As an aside, outside of speed, how do you sign scripts for clients? I love that Powershell encouraged it, but every person I have met has not bought into Powershell, and most certainly invokes "disable the cert check" completely command for all executed Powershell scripts.
The speed difference between PS and cmd.exe is not nearly large enough to justify the incredible hoops you have to jump through to get anything reasonable done in batch. Yes it takes slightly longer to start up, but it has things like native arrays, hashmaps, foreach loops, etc built in to the language! Versus a spaghetti mess of gotos in batch.
I had to do this once to avoid having to duplicate a bunch of build and install logic (that couldn't assume some other scripting language was installed), but because of how limited batch is (powershell was not available at the time), I opted to write a simpler DSL that output one or the other. I could see this project developing in that niche by maybe providing more substantial built-in functions for common build/install script functionality.
I want this to be great; it would solve no end of problems at my workplace.
Unfortunately, "You have to install OCaml (version 4.00.1 or higher) development environment before compiling Batsh" (not to mention "1. Install OPAM. See instructions.") basically makes it a non-starter for my purposes.
Why can't this take a batch file and translate it to Bash? Or vice-versa? Genuine question - I do not have a sufficient understanding of the fundamentals to guess.
They are both hideous languages with myriad diverging features. Translating them into each other would either require extra runtime dependencies or obscene amounts of hideous code in either language.
By coming up with a third language the author could conveniently pick a subset of features that could easily be implemented in both languages without much goat slaughtering.
There's no mention of error handling, which is what really makes Windows batch files completely hopeless for anything involving more than one or two commands. Being able to write code with exceptions and having it compiled to the corresponding mess of ERRORLEVEL and GOTO would be sweet!
(I've switched to just writing everything in JavaScript for WSH. It's ECMAScript 3 and the API has some issues, but it's still a million times better than trying to write any logic in batch.)
I don't like the concept so much. They are their own languages, and I'd rather write very low level ansible primitives and build upon them than rely on a somewhat opaque translation process. Also, all automation I do going forward is PowerShell, not batch.
I could see a lot of places using it, though, so bravo for sharing.
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
What systems do you work on where bash isn't around, but ksh is?
If you're referring to Linux as "certain modern platform", I was using bash on Solaris 1.x 20+ years ago. (Granted, back then I had to compile it myself which may not be an option for many.)
Using Fedora 20, `which ksh` returns nothing. I would think people wanting to adopt a language like this are more likely to be using Linux 2.6 than AT&T UNIX, but I would suspect you're wrong about which one is now more prevalent now anyway. I can't remember the last time I used a *nix box that didn't have bash (or a VERY similar shell) installed by default, and this is certainly a huge step up over having to write both batch and bash independently anyway.
So are we really supposed to install OCaml and compile it or do we use it as a hosted service? I can see that you just post a batsh script and specify your output, but I don't know if that's intended for public consumption. Otherwise this just looks like a POC.
I think you missed the second option in the README, “Install from OPAM” (https://github.com/BYVoid/Batsh/tree/master#install-from-opa...). To summarize, you can install the OPAM system with your package manager with a command such as `brew install opam`, then install batsh with `opam install batsh`. That should give you a `batsh` command that you can use to compile your scripts.
129 comments
[ 3.1 ms ] story [ 190 ms ] threadPerhaps I should just master bash scripting once and for all (I know it's not that complex), but I generally find it unpleasant to do anything that requires control flow or traditional "programming language logic" in bash.
A simple way to bootstrap the compiler with the script itself would be especially nice. Basically, an embedded batsh compiler. Might be an interesting avenue for an enterprising person to look into.
Most of the time I find myself struggling with Bash, it's because a simple script has kept expanding in scope and I'm well into the sunk-cost fallacy in trying to fix "just that one last thing".
But unless you have a really specific environment, I'm pretty sure most modern servers probably have Python or Ruby or some other stack that can be a shell script available. If you're in Bash, it's because you were trying to do something quickly.
This could be very easy. If this can't be rigged with simple shell scripting (in a reasonable way), then it could with straightforward changes to the compiler (such as outputting to standard output). If you don't mind doing somewhat silly things like writing out scripts as temp files, this could certainly be done now.
Currently, "many seconds" is enough time to run an interpreter on the command, connect to a remote machine in Iceland, spin up a new virtual server there, send the command there to be executed, review the execution results for possible exceptions, run a malware scan, fetch the response back, execute the command again on your computer, translate the command and results to Klingon, send them to NSA for archiving, play a quick game of chess with another instance of the shell, and play a congratulatory tune.
Seriously, computers nowadays are fast enough to run a partial compile of your code at every single keystroke while you're writing it. It takes special effort to make a scripting language unusably slow - even an unoptimized interpreter that itself runs on a different interpreter should do just fine.
I needed to do something and looked at using powershell, but in the end I couldn't just distribute it and have it work for whomever would be using my project. It needed to be signed or something. On the contrary, the bat script I wrote just worked and would just work for anyone who used the project.
Powershell is not a magical solution that suits everyone's needs. This kind of blanket statement helps no-one.
I had mixed opinions of powershell when I tried my hand at it. The naming convention and documentation system were well designed, piping objects is an interesting concept, and IDE support was great for a terminal (step through debugger, intelligent auto complete). Despite this, there were numerous quirks and ugly spots that diminished the experience. I felt it was a missed opportunity. This was powershell 3, I can't speak for later versions
Sadly there are far too many people who only know bash and see straightforward conversions of VBScript into PowerShell and think the language sucks or is too verbose.
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.
But I'm guessing you don't really notice the performance difference, you just feel the weight of unused features.
Key feature has to be output that is no less readable than the average bash script. Which it seems to be.
So does smashing your head into the keyboard while holding the shift key.
I use bash but it's not a pretty language.
Yes it does happen that some features get neglected, but we're talking shell scripting here. They could hit the 80% use case and it would be totally useful.
[1] http://haxe.org/
[2] http://www.gwtproject.org/overview.html
For those kinds of simple tasks, the overhead of fully understanding the nuances of bash _and_ bash is way more trouble than the inconvenience of having fewer features available. This is not for bat/sh lovers, it's for those who have to use bat/sh even if they'd rather not.
Having said that, I wouldn't use batsh myself until it does something sane with errors (at least the equivalent of `set -e` in bash).
Batsh -> Bash or Batch
How do you use pipes in batsh?
Just googled it. Doesn't seem to be supported yet: https://github.com/BYVoid/Batsh/issues/17
Sure it is: http://www.microsoft.com/resources/documentation/windows/xp/...
Thank you for sharing.
In terms of performance for very basic scripts (silent software installs, 5-10 lines, registry patching, etc.), I see the performance chart as:
Batch > VBScript > Powershell
in terms of speed. I wish I had tried Jscript, because the ironic Javascript is taking over the world could have meant retro hipster superiority (and scary you could integrate JScript and VBScript into the same script by embedding them in XML type directives and using the WSF system). Now that was scarier than any of this.
As an aside, outside of speed, how do you sign scripts for clients? I love that Powershell encouraged it, but every person I have met has not bought into Powershell, and most certainly invokes "disable the cert check" completely command for all executed Powershell scripts.
Unfortunately, "You have to install OCaml (version 4.00.1 or higher) development environment before compiling Batsh" (not to mention "1. Install OPAM. See instructions.") basically makes it a non-starter for my purposes.
Why can't this take a batch file and translate it to Bash? Or vice-versa? Genuine question - I do not have a sufficient understanding of the fundamentals to guess.
By coming up with a third language the author could conveniently pick a subset of features that could easily be implemented in both languages without much goat slaughtering.
(I've switched to just writing everything in JavaScript for WSH. It's ECMAScript 3 and the API has some issues, but it's still a million times better than trying to write any logic in batch.)
You can also put a thin shim to launch node for the script in case it's in a wsh environment.
WSH is Windows Script Host: https://en.wikipedia.org/wiki/Windows_Script_Host
Also, why hasn't this been around before?
I could see a lot of places using it, though, so bravo for sharing.
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
If you're referring to Linux as "certain modern platform", I was using bash on Solaris 1.x 20+ years ago. (Granted, back then I had to compile it myself which may not be an option for many.)