Hacker News Reader

Comment by zwieback | Hacker News Reader

Looks nice but wouldn't you just use something like Python nowadays?

What if you want to build Python?

Oh, that' easy, you unpack the Python sources and start with:

   ./configure

But what is that? It's not written in Python. It can't be, because you don't have Python yet. It's a shell script.

It's not a hand-maintained shell script; it's written by expanding Autoconf macros (in the M4 preprocessing language) to shell code: essentially a compiler from another language to shell.

A cleaner language which does the same thing could, in principle, replace Autoconf.

A related use for such a language would be install scripts: perform complex actions to install some software, with minimal dependencies on what is already installed.

Writing your language's build system in itself shouldn't be any worse than writing your language's compiler in itself.

The GHC folks are rewriting their jungle of recursive Makefiles in Shake, a Haskell-based build system.

I think you only need the ability to build a cross compiler for this to work.

The "Why not Python/Ruby/Node.js/Lua" section lists 3 reasons the author developed this language...

Bullet 1 says "None of them is preinstalled on all platforms", but OPAM isn't universally preinstalled either.

You can build your scripts to a machine that has OPAM and distribute them to one that doesn't.

OPAM is only needed on the computer you develop the script. Actually you guys shouldn't be so lazy to just write something without reading the README.

but you don't need opam to run the compiled scripts...

The second point says “Functionalities like process piping are not convenient to use” but Batsh itself doesn’t support piping [1], a core feature of shell languages.

[1]: https://github.com/BYVoid/Batsh/issues/17

I love python, but python is not a shell, and it makes an absolutely awful shell replacement. Python is further from a good shell than bash is from being a decent programming language. Some scripts are good, I do use python for some kinds of shell scripts, but most of what I need bash for, python is not a good replacement at all.

But the goal of this is not shell replacement correct? It is a way to write scripts for both platforms. Python has great cross-platform support in that regard: http://hplgit.github.io/edu/ostasks/._ostasks002.html

Yes, you're right. Batsh isn't trying to be a shell replacement, but it is targeting the two shells that you're nearly guaranteed to find one of on any given computer.

I dunno if @zwieback was saying Batsh should target python, or if people should use python instead of Batsh, or something else, but neither of those first two suggestions makes a lot of sense to me.

Python's decent cross platform support doesn't really make it better for shell scripts, and while I use it for some shell scripts, I don't ever default to python. My comment was reacting to the "wouldn't you just", as though python is a natural default choice. In my experience, it's not a good default choice.

It's harder to debug python shell scripts, because you typically can't run individual lines, you typically can't cut and paste parts of it, you can't ever run system commands directly without wrapping it in a python module call, output might not display automatically, and you often have to install something that isn't already on the machine.

Perl is probably still the best in its class of being a decent language while allowing close interaction with shell commands. If I really needed to write a sophisticated shell script (try to avoid that), I'd probably go for Perl.

I'm mostly in agreement about Perl's status, but I'd rather take the small hit in verbosity for the niceness of the rest of Python rather than having to deal with Perl... Yeah it kind of sucks not having the backtick operator, but at least it's not too much of a hassle to do something like:

    from subprocess import check_output as sh
    files = sh(['ls'])
    print files

This has its limits but covers a lot of basic use-cases for the backtick. I think some people first see an alternate way of doing this in Python that's a lot more hairy, even if more flexible, but it doesn't have to be that way...

I don't think windows comes with python installation.

It also doesn't come with any of the tools bash is a glue for, about the only reason one uses bash. At least with Python I can write my own grep and so on, and piping isn't so bad with coroutines and generators.

I think you missed the point of this language. You write code in this language, and then you compile it to get Bash for Linux and Batch for Windows.

I get it, I just disagree with "it's not bundled" as a major disadvantage: neither is your script, and maybe neither is your argument to any `call()`, so you're going to be thinking about deployment in any case.

Could be a great tool for government/enterprise customers who want to avoid the whitelisting process involved around getting anything installed.

IT departments would laugh at you if you said you wanted to install python on their server...

Sure, there are probably use cases, though I'm biased to think there are better options for any specific one except perhaps the project creator's inspiring situation.

IT can laugh, I laugh back when java/flash/excel/browsers are already installed.

Windows has knock-off versions of several unix tools:

grep = findstr

cat = type

which = where

sort = sort

more = more

sudo = runas

Batsh already has some built-in functions which are, i assume, implemented on top of equivalent commands on either platform - for example, readdir() is implemented on top of either ls or dir. It seems plausible that more could be implemented on top of other pairs like these - for example, a searchfile() on top of grep and findstr, impersonate() on top of sudo and runas, etc. Perhaps what it really needs is an extension mechanism to make it easier to define such functions.

At least PowerShell has an ls alias for dir...

And no less!

I didn't know about where, being Windows "native". Thank you.

It also doesn't come with this "batsh" language...

You don't distribute the batsh language. You distribute what you build with it.

Reply on news.ycombinator.com