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 working with larger codebases, e.g. passing a return value variable name into subroutines. The author apparently lacks a bit of understanding on how to write robust batch files, though. Turning
x = "a|b";
into
set x=a|b
is surely going to cause trouble. Quoting the argument to set is also often much easier than correctly escaping every meta-character. And iterating over files by throwing for /f at dir's output will cause trouble with filenames that use characters outside the current legacy codepage (not to mention that /w is the wrong switch and /b must be used, otherwise you get funny "files" back like Volume, in, drive, C, ...). Testing their language and output for correct functioning apparently wasn't high on the list, or at least, as usual, only for bash.
(Bugs reported, but the choice of implementation language makes pull requests a bit hard for me. It also seems that the language is unusable for anything but simple stuff. readdir() returns a string with space-separated file names, but there is no way of iterating over them again (and it's not easy in batch files). Things like iterating over arrays or better support for printing text that does not cause trouble or side-effects have been known for over half a year without a change. I guess the project, while nice, is currently a zombie.)
____
¹ Last thing I really wrote was a deployment script for a website that had to run on Server 2k3 instances where I wasn't allowed to install anything. And I still have a half-written bignum library in numerous batch files somewhere. Only addition worked properly, though.
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.
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.
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.
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 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.
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
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.
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.)
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.
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.)
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.
That files() function will not work properly.
I have an old abandoned project, that has a proper directory listing function for batch, you can take that.
Much of the stuff there is half assed but there is some goodies. Like substring searching and dumping of stdout without using temporary files, which is insanely weird in batch definitely take a look.
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.
[+] [-] ygra|11 years ago|reply
Nice to see this compiler adopting some idioms that make it easier for working with larger codebases, e.g. passing a return value variable name into subroutines. The author apparently lacks a bit of understanding on how to write robust batch files, though. Turning
into is surely going to cause trouble. Quoting the argument to set is also often much easier than correctly escaping every meta-character. And iterating over files by throwing for /f at dir's output will cause trouble with filenames that use characters outside the current legacy codepage (not to mention that /w is the wrong switch and /b must be used, otherwise you get funny "files" back like Volume, in, drive, C, ...). Testing their language and output for correct functioning apparently wasn't high on the list, or at least, as usual, only for bash.(Bugs reported, but the choice of implementation language makes pull requests a bit hard for me. It also seems that the language is unusable for anything but simple stuff. readdir() returns a string with space-separated file names, but there is no way of iterating over them again (and it's not easy in batch files). Things like iterating over arrays or better support for printing text that does not cause trouble or side-effects have been known for over half a year without a change. I guess the project, while nice, is currently a zombie.)
____
¹ Last thing I really wrote was a deployment script for a website that had to run on Server 2k3 instances where I wasn't allowed to install anything. And I still have a half-written bignum library in numerous batch files somewhere. Only addition worked properly, though.
[+] [-] blueskin_|11 years ago|reply
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.
[+] [-] rmchugh|11 years ago|reply
[+] [-] jack-r-abbit|11 years ago|reply
[+] [-] mlwarren|11 years ago|reply
Thank you for sharing.
[+] [-] 616c|11 years ago|reply
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.
[+] [-] nailer|11 years ago|reply
[+] [-] bithush|11 years ago|reply
[+] [-] yulaow|11 years ago|reply
[+] [-] meowface|11 years ago|reply
[+] [-] eddiegroves|11 years ago|reply
[+] [-] dpweb|11 years ago|reply
[+] [-] innocenat|11 years ago|reply
[+] [-] bkeroack|11 years ago|reply
[+] [-] ams6110|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] kolev|11 years ago|reply
[+] [-] danielnaab|11 years ago|reply
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.
[+] [-] neilellis|11 years ago|reply
Key feature has to be output that is no less readable than the average bash script. Which it seems to be.
[+] [-] noir_lord|11 years ago|reply
So does smashing your head into the keyboard while holding the shift key.
I use bash but it's not a pretty language.
[+] [-] PeterisP|11 years ago|reply
[+] [-] unexistance|11 years ago|reply
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
[+] [-] TallGuyShort|11 years ago|reply
[+] [-] michaelcampbell|11 years ago|reply
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.)
[+] [-] aaronetz|11 years ago|reply
[+] [-] kolev|11 years ago|reply
[+] [-] Sami_Lehtinen|11 years ago|reply
[+] [-] ptx|11 years ago|reply
(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.)
[+] [-] tracker1|11 years ago|reply
You can also put a thin shim to launch node for the script in case it's in a wsh environment.
[+] [-] xkarga00|11 years ago|reply
[+] [-] tootie|11 years ago|reply
[+] [-] roryokane|11 years ago|reply
[+] [-] chrisdevereux|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] callesgg|11 years ago|reply
http://sourceforge.net/projects/scriptconvert/
Much of the stuff there is half assed but there is some goodies. Like substring searching and dumping of stdout without using temporary files, which is insanely weird in batch definitely take a look.
[+] [-] tokenrove|11 years ago|reply
[+] [-] eponeponepon|11 years ago|reply
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.
[+] [-] tinco|11 years ago|reply
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.
[+] [-] dtech|11 years ago|reply
[+] [-] mrcharles|11 years ago|reply
[+] [-] talles|11 years ago|reply
[+] [-] notinreallife|11 years ago|reply
[+] [-] Maken|11 years ago|reply
[+] [-] giancarlostoro|11 years ago|reply
[+] [-] parallelist|11 years ago|reply