Comment by thinkpad20 | Hacker News Reader

Comment by thinkpad20 | Hacker News Reader

The idea is interesting, but ultimately the utility of this seems limited. The differences between windows and Unix are more than just the shell language involved; shell scripts are typically deeply intertwined with the system in question, to the point where it's often not the case that a bash script will even run reliably across different Unix systems, much less on windows. Also, you can already run bash on windows, so once again the problem doesn't seem to be the language per se. I can only imagine how difficult it would be not just to design a script that would work properly on both platforms, but to debug the cases where it didn't.

Also, as others have noted this language doesn't support redirection, which in my mind makes it practically useless beyond toy applications. I've written hundreds of bash scripts and I don't think any of them didn't make heavy use of pipes and redirection. I'm also not sure if the language supports running processes in the background, traps, magic variables like $!, extra options, subshells, file globbing, etc, all things that many real-world scripts use. Bash scripts often use many programs available on Unix systems as well, such as find, grep, readlink, xargs, and other things that aren't part of the language per se. Unless those are ported over too, writing useful scripts would be almost impossible.

Finally, I don't think the author has made a convincing argument that such a language is even needed, when languages like perl/python/ruby exist for when the task is complex enough to require a more powerful language. On the other hand, if the project is (as I suspect) purely for fun and interest, then by all means :)

The attraction for me is not about portability, it's about having a better language to write CMD script.

Even when you know you have Python available sometimes you still need to glue things together with CMD.

> sometimes you still need to glue things together with CMD

why? is there something cmd can do that python can't? one example is enough...

It's not about can or can't I think. Examples: Language runtime can't be installed, system locked down with deepfreeze, not enough permissions..

Those aren't normally solved with scripting. However, any language with the ability to issue arbitrary system commands can accomplish everything a command line can.

Then how will batsh get installed?

Isn't the entire premise of batsh that it compiles to bat?

Why would you need to install batsh?

I don't use windows much anymore so there might be a better way to do this, but I'll propose a use case: Automating the installation of python on a fresh machine.

How are you going to install batsh though?

you don't need to install batsh. you maintain your code in batsh, compile to bat and have that up on your page as a download.

Even if you did distribute bat files online Windows would block downloading or running them by default so they are not a useful method.

Or, if you have developers, some on Windows and some on *nix, check in the batsh and its outputs.

You generate bat and sh files during the build, like deb or exe files.

Fresh machine where and for whom? I doubt a simple batch script will get you very far (setup.exe exists for a reason...), and I doubly-doubt you would have enough overlap in the process that something that can convert the steps to bash would be an advantage. The only advantage I see for batsh is that it looks nicer to write in for the tiny subset of batch it supports. But then so is pretty much anything else -- it wouldn't surprise me if someone has already written a DSL in a well known language that can output to batch or powershell, we don't need a whole new language for this.

Ok, I'll try another use case: Political differences (specifically licensing). This project appears to be licensed under MIT, and python appears to be licensed under !MIT. I don't know what the implications are for the licensing of machine-produced shell code, or binary versions of Python, but I'm sure there are companies out there that would have opinions to favour one alternative over the other for reasons other than the technical merits of the choice.

Maybe. Python is under an MIT-like license, so you're fine, but if it were under e.g. the GPL you could still look to see if they have some form of runtime exception as GCC does. In any case it's rare for a company that's not well-established to care more about licensing that technical merit (and even any that do, the typical approach is to ask to buy a separate license if possible), and it's also rare that a company would use such a tool as this (created as a hackday project, in Ocaml, according to the author) rather than finding an alternative that meets their licensing criteria or just developing it in-house since it's not that big a tool and lacks a lot of useful capabilities like piping.

In that case you would use the chocolatey package manager bootstrapped by powershell to silently install Python.

It's a oneliner in powershell followed by choco install Python.

Who cares if Python can technically do it? If you have a CLI tool based around Bash, why would you want to rewrite it in Python and have to support it yourself and spend those man hours doing it?

Because then you wouldn't have to write in Bash...

Or BAT. I can live (reluctantly) with Bash, but Windows batch file is just brutal.

The context of this article and all of these comments is writing new scripts, not rewriting old scripts. If you have a completed script that does everything you want, then none of this applies.

These days you probably want Windows Powershell. It's built on the .NET framework so it's pretty darn powerful and AFAIK is available by default on every modern WinOS.

Powershell _is_ great (I help run an OSS project written in Powershell), but it has a long start-up time. If you're doing it as a pre-build step for example, you don't want to add potentially seconds (!) to your build just to use powershell.

Do you use -noprofile? (you probably should for build steps, or else make sure all your build environments have a similar profile to yours) Then the startup time is usually much better - at least I haven't seen it going over some 100s of mSec.

Startup time used to be horrible in Windows 7 (v2, I think), but they improved it a lot since then. It starts instantly for me on my Windows 10 machine here.

Is there a linux or mac build of Powershell? After all this years hearing it is not that bad i would really love to try it a day or two

I loved the idea.

Some years ago, I was making a project that many parts of the build process depended on simple file copies (that this can do right) and ImageMagik calls (that are the same in all OSes)

I ended having to keep writing the same scripts over and over again in Batch and Bash, it was quite a pain to maintain, and it was obvious that there had to be some way to do it automatically (port one to the other, or generate both).

This software has my situation as the perfect use case, when you need to script command line tools that exist in both platforms.

Why can't you use the windows versions of bash?

Isn't that only available on Windows 10, and only very recently?

There have been many attempts to bring Bash to Windows before WSL. Git for Windows ships with a Bash port based on Msys (IIRC).

So how to install it? Windows users are extremely lazy, they often just wait for a “click-and-run”.

I think it's a limitation more on the windows batch end. As mentioned, it's tricky for historical reasons.

Powershell would be closer to Bash, functionally speaking. An adapter between the two would be more functional- however doesn't satisfy the point of batsh, which assumes cleanish-builds of the OS in question.

Powershell introduces more complications, with functions like Invoke-WebRequest being given the alias "curl". At a minimum, you would get a type validation error, as Invoke-WebRequest by default gives back headers and other data as objects inside a larger object, not just the content string that curl.exe defaults to returning.

This should work in both bash and PS, with different results:

  > curl HTTP://example.com > file.html

Isn't that just what a compiled language would sort out for you? On Bash it'd compile to

curl HTTP://example.com > file.html

and on PowerShell it'd become

(curl HTTP://example.com).Content > file.html

There is an "adapter" between PowerShell and Bash - Pash (http://pash.sourceforge.net)

Reply on news.ycombinator.com