Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Create a New Unix Shell?

oilshell.org

Post reply on HN
Print view View original

61–63 of 63 posts

Re: Why Create a New Unix Shell?

#61

Post by chubot »

peter_d_sherman wrote: post #40
chubot wrote: post #24

Earlier quoted context omitted.

(author here) Thanks for the comment! I do think you hit on something interesting, and it partly explains why the project is so big :) To me, shell and Python/JS feel kind of similar, and that was sort of the thesis at the start of the project. But if you just incrementally add features to Bourne shell, you basically get Korn shell, which is where bash got all the "bashisms" that people don't like. This paper was sur…

>"It's a lot more work to make something like Python or JS! Garbage collection is one issue; shells don't have it because they don't have recursive compound data structures or true functions." An excellent point! >"Yes pipelines are a big deal and the runtime is solid now so they can be enhanced." Maybe synchronous (aka, guaranteed linear) and asynchronous (no guarantees) are better ways to look at it... For example,…

Yes being able to store the FDs for pipes in variables is something that would make it more explicit and flexible. (It could also introduce deadlocks though)

Also, dgsh is along these lines: https://www.spinellis.gr/sw/dgsh/#compress-compare

It appears to use Unix domain sockets, not pipes.

I think I might want to use the Ruby-like blocks for syntax, something like

    grep FOO *.py | wc -l | sort -n

    pipeline {
      pipe :p1  # variables that are pipes
      pipe :p2

      # this syntax isn't great but shows the idea
      grep FOO *.py > &p1
       &p2
-----

Although I think richer pipelines make sense, structured data will probably come first:

https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil

Re: Why Create a New Unix Shell?

#62

Post by wpietri »

pdmccormick wrote: post #26
wpietri wrote: post #17

This reminds me: why isn't there a good Python shell? Something with, as the author says, a "domain-specific language for dealing with concurrent processes and the file system", but otherwise basically Python? I'm sure people must have tried, so I guess there are fundamental incompatibilities between the two?

You might be interested in Xonsh: https://xon.sh/

Uh oh. I've always stuck with Bash, because it's guaranteed to be on absolutely everything, and that's valuable for ops work. But this looks so much better! Thanks for pointing it out.

Re: Why Create a New Unix Shell?

#63

Post by peter_d_sherman »

chubot wrote: post #61
peter_d_sherman wrote: post #40

Earlier quoted context omitted.

>"It's a lot more work to make something like Python or JS! Garbage collection is one issue; shells don't have it because they don't have recursive compound data structures or true functions." An excellent point! >"Yes pipelines are a big deal and the runtime is solid now so they can be enhanced." Maybe synchronous (aka, guaranteed linear) and asynchronous (no guarantees) are better ways to look at it... For example,…

Yes being able to store the FDs for pipes in variables is something that would make it more explicit and flexible. (It could also introduce deadlocks though) Also, dgsh is along these lines: https://www.spinellis.gr/sw/dgsh/#compress-compare It appears to use Unix domain sockets, not pipes. I think I might want to use the Ruby-like blocks for syntax, something like grep FOO *.py | wc -l | sort -n pipeline { pipe :p1…

That's another excellent point, by the way...

All Unix (and derivative OS utilities) typically pass unstructured raw data to one another via pipes...

That's sort of a good thing and a bad thing at the same time...

It's great for such things as binary files, binary streams, anything binary in nature...

But equal-and-oppositely, it's terrible for say, if I wanted to put the output of a 'ls -al', and I wanted to put all of those fields into something like a structured XML or JSON or BSON or what-have-you.

I also like your point about FD's for pipes... that's a good idea too.

Yes, I could see deadlocks as possible, but then, maybe yet another extra step of engineering/forethought is necessary -- how do we manage locking in those scenarios? Maybe we could create timers that automatically break a deadlock after a certain number of seconds, and/or put the lock explicitly under program control (like the FD's for pipes), etc., etc.

Anyway, some fascinating stuff!

>"Although I think richer pipelines make sense, structured data will probably come first:

https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil"

Looks like you've been doing your homework!

Post reply on HN