Hacker News Reader

Comment by marshray | Hacker News Reader

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.

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

> 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.

Reply on news.ycombinator.com