Hacker News Reader

Comment by jigglesniggle | Hacker News Reader

I think you're reading my comment the wrong way: I meant to say that doing e.g. piping in Python is a lot of pointless work (pomp), as you agree.

This is perhaps one big benefit but not one that is exclusive to a sh-like language. Instead I would like to see a language with strong flow control or metaprogramming capabilities take on processes as a first class citizen. Perl is probably the closest but still has some warts related to redirection.

The best pattern I have seen is encapsulating business logic into Python or Go and then if really necessary piping it to another script. But, often, if you do this you can just keep the piping internal using data structures.

Unix-pattern facilities work very well for interactive use, which tends to be simple, exploratory, and trial-and-error. But a project's build script may not be simple.

View on HN

Perl was literally born because Larry Wall reached the limits of what could be done with a combination of Shell + C + Unix utils.

In fact this is how Perl 1 looks: https://st.aticpan.org/source/RCLAMP/perl-1.0_16/

https://github.com/Perl/perl5/commit/8d063cd8450e59ea1c611a2...

If you pardon the shameless self promotion; I'm working on something just like that:

https://github.com/lmorg/murex

It currently has:

* Proper error handling (eg try and catch blocks)

* unit testing and debugging frameworks to help with development and maintainability

* data-type aware, including complex types like how CSV, JSON and YAML are all handled as memory structures and thus the same tools can query any structured data format without understanding it's contents

* while still ostensibly working the same way as a traditional POSIX shell

There's also some work on improving the REPL experience too where I've included:

* automatic man page parsing for flags

* a "tool tip text" like hint line which tells you where commands reside on the fs, what it does, etc. Which is handy if you're trying to debug an existing commend.

* if you paste multiline text into the console you get offered a chance to preview the text before executing it (handy if, like me, you're pretty useless at copy/pasting content reliably)

* a package management system so you know exactly which functions and imported scripts are loaded from which sources (no more "where did that autocomplete suggestion / alias / etc get loaded from?"

There's a few other features like support for events and such like, but they're not yet documented.

The shell is currently beta but I've been using it as my daily driver for about 18 months now. There are still quite a few bugs, plenty of places where code needs to be rewritten for performance and lots of stuff isn't yet documented (though the documentation is pretty good already considering it's only me working on it). So don't expect a finished product. However I do think I'm at the stage where I'm ready for more users to have a play and I welcome PRs, issues raised, general comments and feedback, etc.

# end of shameless self promotion :D

Seems quite similar to Elvish (https://elv.sh/); have you checked it out?

Sorry, only just seen this comment. Just in case you're still following this thread and interested in a reply:

I'm aware of Elvish and really impressed with what's been built and the traction that has gained. There is definitely some overlap between murex and elvish but also a lot of area's where our shells differ.

I think there is sufficient difference between the two shells to justify their existence.

Oh, definitely. Just thought it was something you should check out and I didn't see it mentioned anywhere.

Nice project, look forward to seeing a HN post on it!

Thank you

> Perl is probably the closest but still has some warts related to redirection.

I wholehartedly agree on perl but can you expand on the redirection warts? I seldom had problems with perls' FHs, while, on the contrary I seem to be unable to wrap my head around the contorted syntax involved in bash's handling of descriptors - especially when more than 2 handles are involved.

Well -- I was comparing Perl to Python in this case. There is roughly the same amount of boilerplate and both are easier to read than bash's redirection.

The wart is that you need IPC::Open3 or equivalent because Perl's intrinsics can not synthesize the pipe operator (though you will think that they can) if you need to insert yourself into the middle of a chain of commands.

Nowadays there are decent wrappers for calling Open3 but more commonly you just find people running one half of the command, buffering the output, and passing it to the second half.

Aw, right. I'd forgotten about IPC::Open3. Because I did not want to think about it, mostly (and so, I usually do exactly what you say people do :-) )

My mistake - I managed to completely misinterpret what you meant. I agree with your comment!

I think tcl is exactly in this niche. I haven't had time or an excuse to learn it, but it seems to fit perfectly. Haven't yet found out why it seems to be dying away

Following page has Tcl code written by antirez to create command pipes:

https://wiki.tcl-lang.org/page/Pipeline+programming

A collection of pipeline programming implementations in Tcl:

https://wiki.tcl-lang.org/page/Commands+pipe

So PowerShell then?

PowerShell removes the pomp from running processes and adds it squared into running normal functions.

Isn't that Windows only?

Not any more: https://github.com/PowerShell/PowerShell/releases/

I quite like Powershell on Windows, but I'm not sure I dare try it on Linux. I think it might make my head explode.

It's quite clear Microsoft are only a couple of years from either an official linux distro or some halfway house of using a linux kernel internally for major os functionality, so it makes little sense learning some new(ish) shell when you could just use bash (via wsl or whatever).

No, but I haven't seen many Linux users (admitting to) using it.

Reply on news.ycombinator.com