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

51–60 of 185 posts

Re: Four features that justify a new Unix shell

#51

Post by boogies »

Denvercoder9 wrote: post #45
boogies wrote: post #40

Earlier quoted context omitted.

> feels a lot more like programming When I want to program a script, I can use a scripting programming language like Python with its object oriented nature. When I want to interactively command my computer I can use a shell like bash or zsh. Do one thing and do it well.

There's an enormous grey area in-between them though, and something that bridges that area can be insanely powerful. Making it easy to go from doing something by hand to fully automating it creates value. It's one of the main strengths of a command line interface.

I wouldn’t call it enormous — Python can be used as an interactive shell (there’s even a toy “operating system” that uses it as the only text shell), and traditional shells can write (simpler) versions of software that’s normally made in Python https://news.ycombinator.com/item?id=23643096

Re: Four features that justify a new Unix shell

#52

Post by fuzzy2 »

wvenable wrote: post #37
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.

As a software developer, not a sysadmin, I have real trouble with Powershell. They didn't tradition-break enough and it's like some bastard child of .NET and Bash. I think most people have an easier time understanding https://www.cs-script.net . It's powerful but the syntax and semantics are maddening. It's going to be entrenched in the Windows world for the next 20 years and prevent anything better from coming along…

Yeah, I had trouble with PowerShell’s auto-magic array handling more than once. I see how it can be convenient in the REPL, but it’s just terrible when writing scripts.

Your array logic returned just one element in this folder? Why, we’re unwrapping that!

Re: Four features that justify a new Unix shell

#53

Post by chubot »

breatheoften wrote: post #21
chubot wrote: post #11

Earlier quoted context omitted.

(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…

So is the normal usage path to start using osh for interactive use and then use osh in a bash compatible mode to write scripts that are less buggy but can still be run on bash? Or is it more common to write scripts that tend to then require the osh runtime exist in whatever context they are deployed to?

Right now, I use osh interactively in a very bash compatible mode.

Then at the top of my scripts I put this if I still want to run with bash:

    shopt -s strict:all 2>/dev/null || true
Or this if I don't need to run with bash anymore:

    shopt --set oil:basic
Example: https://github.com/oilshell/oil/blob/master/test/spec.sh#L9

docs in progress: https://www.oilshell.org/release/0.8.3/doc/oil-options.html

Having the OSH runtime exist everywhere is something we should work on: https://github.com/oilshell/oil/issues/463

Re: Four features that justify a new Unix shell

#54

Post by chubot »

3np wrote: post #12

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.

Yes absolutely! That's been on the table for along time, and we even have a nascent xargs from a contributor (that has languished -- I need help!)

Let's discuss on the issue if interested: https://github.com/oilshell/oil/issues/843

Oil is easy to prototype (it's just Python code), so anyone who wants to make this feature their own should feel free to dive in :)

A lot of people have ideas, which may or may not be implementable with fork(), wait(), pipe() and dup(). Anything that can be done safely with those syscalls is basically viable.

The syntax is generally the easy part compared to the runtime execution. Oil has first-class blocks already which will help a lot.

----

Related: I also want to fix redirect and here doc syntax (in a compatible way):

https://github.com/oilshell/oil/issues/841

https://github.com/oilshell/oil/issues/832

Re: Four features that justify a new Unix shell

#55

Post by Denvercoder9 »

boogies wrote: post #51
Denvercoder9 wrote: post #45

Earlier quoted context omitted.

There's an enormous grey area in-between them though, and something that bridges that area can be insanely powerful. Making it easy to go from doing something by hand to fully automating it creates value. It's one of the main strengths of a command line interface.

I wouldn’t call it enormous — Python can be used as an interactive shell (there’s even a toy “operating system” that uses it as the only text shell), and traditional shells can write (simpler) versions of software that’s normally made in Python https://news.ycombinator.com/item?id=23643096

To clarify: I didn't mean the tools, they do indeed overlap in functionality. I meant the activities you refered to, "program my computer" and "interactively command my computer".

Re: Four features that justify a new Unix shell

#56

Post by chubot »

l0b0 wrote: post #19

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…

The paragraph right below that mentions that Oil has "read -0", which consumes the find -print0 input.

I also link to my Git Log in HTML post [1] from 3 years ago, which is ENTIRELY about the NUL byte solution :)

-----

Shell scripts can use both formats, but the advantage to QSN is that it preserves the line-based nature of shell.

Say I want to use wc -l, awk, or grep. Then the QSN-lines format is better than the NUL format.

Also, you can transmit a series of say SHA256 checksums in binary format with QSN-lines, or some other binary format.

Even entire JPG files, audio clips, wasm files, whatever. It's "8-bit clean" (and so are Oil strings).

[1] https://www.oilshell.org/blog/2017/09/29.html

Re: Four features that justify a new Unix shell

#57

Post by chubot »

ilaksh wrote: post #33

Just in case people are looking for something really new in a shell: besides Oil, check out fish shell. The killer feature for me is its autocompletion -- its basically psychic.

Yes, fish and Oil are very complementary (see the note about fish in the blog post)

Re: Four features that justify a new Unix shell

#58

Post by chubot »

quotemstr wrote: post #36

These things might justify making a non-Bourne shell, but they don't justify making a greenfield shell: the fish shell already has all these features, and since we all benefit by reducing shell fragmentation, I think the author ought to work on hacking on fish more before making yet another shell.

fish and Oil are very complementary (see the note about fish in the blog post)

Re: Four features that justify a new Unix shell

#59

Post by aeyes »

ritchiea wrote: post #7
xilni wrote: post #4

I love the direction this wants to go in. So many of these are reasons why we've banned new shell scripts on our projects and instead make python scripts.

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

Working with large amounts of files or analyzing the content of large files. Not only will you be faster in glueing commands together with pipes but tools like find, grep, sed, awk, cut and so on will also perform much much better than interpreted languages.

Also, I'd never prefer using the stdlib of Python/Ruby/etc for system commands like cp/chmod etc. It takes way more boilerplate code than a oneliner.

Re: Four features that justify a new Unix shell

#60

Post by pierrebai »

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it.

Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

Post reply on HN