Hacker News Reader

Comment by cnity | Hacker News Reader

Your ideas are something I wrestled with while I was writing (a very similarly named) crsh[0]. I chose to avoid trying to reimplementing commands and instead stuck with an unstructured environment, but with the ability to parse output using an expandable set of parsers and use inline JavaScript to operate on it. I agree with what you say about perl, but the number of users with experience in perl is -- at least in my bubble -- very small compared with more modern languages.

[0] https://crwi.uk/2020/07/12/crsh.html

View on HN

While I have some relatively extensive experience with Perl, I'd rather write assembler using morse than touch that ever again. The language is one guy's not-too-well-thought-through hack that gained enormous traction by filling a void, and from there grew far too organically. There are lots and lots of cryptic ways to do the most mundane things, lots of inconsistencies, the language really makes it hard to write software that isn't terrible to maintain.

Exactly. This is common with shell scripting languages. They feel like some awful duct tape, when in fact the perfect primitive for joining separate concerns already exists (the pipe). Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me.

> Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me.

# ls | grep foo

This involves two programs written in nicer language (C).

# ls | rg foo

This involves two programs written in nicer language (C & Rust).

Feel free to come up with JS program that does something well and/or is usable in pipeline. I think you're missing the point of the shell.

Aren't we talking about "a better shell scripting language"? At the point where a Perl program becomes "hard to maintain", what would the bash alternative even look like?

Perl code is often written once and then runs for years without issue. I have on occasion fixed broken Perl scripts despite having practically no experience with the language. It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason".

>It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason".

I would intuitively agree with you as there are hundreds of unnoticeable perl scripts doing their job, but as someone with moderate experience with the language, I can say that when I did maintenance tasks, they were mostly the second kind.

You are right, but none of those criticisms apply to Tcl, which is both beautiful and integrates really well with the Unix environment. I won't say that it is perfect, but it is really, really good. A better choice than Perl where Perl is used, a better choice than Lua almost everywhere Lua is used, often a better choice than Python.

Tcl is horribly, terribly under-appreciated. It is one of the great might-have-beens of modern computing, almost as much as is Lisp.

Eh, having used both Tcl and Lua, I definitely think Lua is the better of the two when it comes to a scripting engine for games.

And I think Lua is more elegant than TCL overall. TCL's stringiness really gets clumsy in certain types of programs, and it's a much larger target than Lua overall.

Not to say that TCL is bad, but I'm glad that dict-based languages prevailed over TCL's string-based-ness

This is a very interesting project. I really like the combination of languages and the way you've implemented it. I already see some opportunities to use it.

Thank you! It's pretty buggy at the moment, and maybe frustrating to use since it's missing some important shell features, but any feedback is always welcome.

Yeah I've just installed it and seen eg. the autocompletion on ls isn't how I'm used to. I will keep playing around and watch for progress because I really like the idea.

I especially see this being useful in my CI environment which has a handful of functions, some json and yaml parsing (using jq and python respectively), etc. It's a little cumbersome at the minute but not so much to switch from bash and the rest of the project is JS anyway so it would be good to be consistent.

Excellent. If there are things you notice, please feel free to raise as an issue, and pull requests are always welcome!

> useful in my CI environment

For sure. I've been meaning to play around with getting a docker image with the shell set as the default. It's definitely a use-case I had in mind.

I'm very impressed with what works so far by the way.

Reply on news.ycombinator.com