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

Four features that justify a new Unix shell

oilshell.org

Post reply on HN
Print view View original

11–20 of 185 posts

Re: Four features that justify a new Unix shell

#11

Post by chubot »

breatheoften wrote: post #3

Are there any transpile to bash languages? I like the idea of a language that allows for a better experience in writing shell scripts -- and produces shell scripts with fewer bugs on the output side. But i wonder if a transpile approach wouldn't be better in the long run

(author here) Yeah I've been asked that before, and there are some things you can fix with a transpiler, but somethings you can't.

That's why the tagline to Oil is now "our upgrade path from bash to a better language AND RUNTIME".

The shell runtime needs to be fixed too, e.g. the error handling mentioned in the blog post and that I follow up on here: https://news.ycombinator.com/item?id=24872986

You might be able to compile that to some really long bash, but I don't think it works in general, because editing deployed scripts to fix stuff is useful (yes in production, but also on your own machine. Think of all the shell that people put on it, like virtualenv, nix-shell, rustup, etc.)

You don't want to end up with the JavaScript problem: you have a dynamic language, but ALSO A BUILD PROCESS, which is basically the worst of both worlds.

Re: Four features that justify a new Unix shell

#12

Post by 3np »

Two ergonomic issues in POSIX/bash not mentioned that I’d like to see a new shell improve on:

- splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph.

- native parallelization; I have to look in man every other time I use parallel.

Re: Four features that justify a new Unix shell

#13

Post by chubot »

neolog wrote: post #10
chubot wrote: post #9

Earlier quoted context omitted.

Yes, a couple answers here: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-we-dis...

> It won't work. It would be like trying to convince people who are paid to write PHP not to write PHP. Many people have wasted breath on that, but important sites like Wikipedia are still written in hundreds of thousands of lines of PHP. If they're gonna keep writing bash, why would a new shell language help? > Even if a new line of shell never gets written, there will still be a huge installed base of shell scripts…

Because you can run your bash scripts with Oil. The tagline is:

It's our upgrade path from bash to a better language and runtime. [1]

It's basically the same as JS -> TypeScript, or PHP -> Hack. It's a saner language (and runtime) that runs existing code.

-----

Shell is good for creating Unix systems because of the tools it provides. Ones that deal with the file system and heterogeneous processes (i.e. stuff you didn't write in different languages).

It's hard to explain, but if you work in that area, you'll very quickly see it. You could also do something like Linux From Scratch [2] and it will be very clear why shell is used.

[1] http://www.oilshell.org/

[2] http://www.linuxfromscratch.org/

Re: Four features that justify a new Unix shell

#14

Post by abnry »

I am very sympathetic to this. I like the concept of a shell (there's a place for light scripting that doesn't involve python or perl or ruby), and appreciate what bash can do, but after encountering enough of the "gotchas" and just ugly behavior, I'm not really motivated to master it. The biggest reason to learn it seems to be the fact that everybody uses it and has done so for years.

We need something akin to Jupyter notebooks for unix.

Re: Four features that justify a new Unix shell

#15

Post by ritchiea »

chubot wrote: post #9
ritchiea wrote: post #7

Earlier quoted context omitted.

Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?

Yes, a couple answers here: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-we-dis...

Ok well #1 does not apply to me because I don't write a lot of shell. Ditto #2. So it would be better to understand your case for #3, when is shell the best tool for the job when writing a new script? Why?

Re: Four features that justify a new Unix shell

#16

Post by solarkraft »

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature.

It feels a lot more like programming and actually gives you useful suggestions right inside the terminal!

On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.

Re: Four features that justify a new Unix shell

#17

Post by klodolph »

solarkraft wrote: post #16

OSH is probably a good incremental improvement over bash, but I also enjoy using the significantly more tradition-breaking Powershell with its object oriented nature. It feels a lot more like programming and actually gives you useful suggestions right inside the terminal! On Linux the auto completion behavior is luckily less obnoxious than on Windows and it doesn't have the multi second startup delay either.

Agreed... PowerShell is actually interesting and it feels a bit more like you're inside a shell-like REPL rather than just a fancy shell.

Re: Four features that justify a new Unix shell

#18

Post by chubot »

abnry wrote: post #14

I am very sympathetic to this. I like the concept of a shell (there's a place for light scripting that doesn't involve python or perl or ruby), and appreciate what bash can do, but after encountering enough of the "gotchas" and just ugly behavior, I'm not really motivated to master it. The biggest reason to learn it seems to be the fact that everybody uses it and has done so for years. We need something akin to Jupyt…

Yes, I would like for that to happen:

Shell as an engine for TUI or GUI https://github.com/oilshell/oil/issues/738

C++ code should be embeddable in another program https://github.com/oilshell/oil/issues/822

I think you can already use bash in Jupyter, but the integration is necessarily kind of coarse.

I don't know exactly what a good integration is, but I'm looking for people interested in UIs to help me figure it out. At the very least, you can use Oil's parser to provide completions:

http://www.oilshell.org/blog/tags.html?tag=interactive-shell...

(which is a separate integration point that running commands)

Also, I mentioned in the blog post that there's some interest from maintainers in combining the fish shell and Oil. However someone has to do that work, and there's a lot of it!

https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback

----

Also, I use shell scripts as a productivity tool like a Jupyter notebook:

http://www.oilshell.org/blog/2020/02/good-parts-sketch.html#...

I think we need to come up with a clever name for it -- some people call it "Taskfile", "go script", and I call it "run.sh".

The basic idea is that I don't remember how to do things with computers, because there are too many things to do.

I just remember WHERE I WROTE IT DOWN in a shell script. Some people write their notes in text files; I write them in executable shell scripts.

Re: Four features that justify a new Unix shell

#19

Post by l0b0 »

There are some good ideas in here, but `--qsn` is described[1] like this:

> Print filenames ONE PER LINE. If a name contains a newline or other special char, it's QSN-encoded like 'multi-line \n name with NUL \0 byte'

This is a bad idea. There is a solution which already works. Just terminate every filename with NUL and you're done. Trying to make something "sorta kinda human readable" is a mistake when dealing with what is effectively arbitrary byte sequences which can contain anything except for NUL. Consistency makes the consuming code much simpler.

That said, QSN is a great idea for human input.

[1] https://www.oilshell.org/blog/2020/10/osh-features.html#safe...

Re: Four features that justify a new Unix shell

#20

Post by Splognosticus »

abnry wrote: post #14

I am very sympathetic to this. I like the concept of a shell (there's a place for light scripting that doesn't involve python or perl or ruby), and appreciate what bash can do, but after encountering enough of the "gotchas" and just ugly behavior, I'm not really motivated to master it. The biggest reason to learn it seems to be the fact that everybody uses it and has done so for years. We need something akin to Jupyt…

I haven't tried it personally, but there is a notebook-style terminal that might interest you, aptly-named Shell Notebook.

https://shellnotebook.com/

Post reply on HN