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

41–50 of 185 posts

Re: Four features that justify a new Unix shell

#41

Post by viraptor »

chubot wrote: post #18
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 ou…

> 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.

Ignoring the language bit, in write impressed with both AutoIT and PowerShell GUI integration. They really allow you to create script-like utilities.

Re: Four features that justify a new Unix shell

#42

Post by onlyrealcuzzo »

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…

The biggest reason to master the shell (I think) is that if you will discover a shocking amount of things you can quickly accomplish piping between the standard Unix binaries (essentially the standard library).

Re: Four features that justify a new Unix shell

#43

Post by Denvercoder9 »

chubot wrote: post #24
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.

I should turn this into a FAQ, but PowerShell is natural on Windows, where the OS provides objects (either via the .NET VM, or COM and .DLLs, etc.) A Unix shell like bash or Oil is natural on Unix, where the OS uses text files. And in distributed systems where data is JSON, YAML, XML, protobuf, msgpack, etc. not objects. So basically shell is a "situated" language, and the easy of accomplishing any given task depends…

There's nothing inherent about an object-based design that limits what you can glue together. Yes, it might require a bit more effort to transform object formats, but today's untyped shell also creates problems that don't exist in a typed environment.

Re: Four features that justify a new Unix shell

#44

Post by viraptor »

strbean wrote: post #27
chubot wrote: post #13

Earlier quoted context omitted.

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…

Seems like a big part of why shells are so much better for certain tasks is because of a failing of more general purpose languages. Working with the filesystem, spawning processes, and orchestrating io streams. Shells could almost be considered DSLs for these things, plus some session / state management. So I think a good question is this: why can't we make these things equally easy to do in a more general purpose la…

Because on the shell side you want simplicity and on the programming side you want control. Shell pretty much has to default to "foo" meaning "execute command foo from $PATH" or almost every line will have useless overhead. GP language needs to make that explicit or it will be a footgun where you don't know what's a command / variable / function. And that's before we get into how the file descriptors / redirects are handled.

One shell which tries to merge those is ipython with the sh profile https://ipython.readthedocs.io/en/stable/interactive/shell.h...

Re: Four features that justify a new Unix shell

#45

Post by Denvercoder9 »

boogies wrote: post #40
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.

> 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.

Re: Four features that justify a new Unix shell

#46

Post by e12e »

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…

I think having both is a good idea. Sometimes maybe you get your list of path names from a Here-document, for example.

Re: Four features that justify a new Unix shell

#47

Post by oblio »

diroussel wrote: post #29
jayd16 wrote: post #26

Earlier quoted context omitted.

> JSON, YAML, XML, protobuf, msgpack, etc. not objects. JavaScript Object Notation doesn't map well to objects?

An object should have identify, state and behaviour. JSON only encodes state.

On the other hand, for interoperability, passing around behavior is horrible. It's either a security risk or a compatibility (forward/backward) risk or both.

We should try to pass around just state and keep objects strictly for code.

Re: Four features that justify a new Unix shell

#48

Post by oblio »

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 is incompatible with bash...

Re: Four features that justify a new Unix shell

#49

Post by e12e »

Splognosticus wrote: post #23
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.

> - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. Could you elaborate a little on what you mean by this? bash already has the ability to redirect STDERR and STDOUT independently, and when you introduce named pipes into the mix things can get really fancy (probably too fancy, this is about where your script stops being a script and starts being a program written i…

I imagine an easy/intuitive way to set up FIFOs for stdout/stderr with redirection, maybe? A way to say: for this following section, I want stderr to go trough "|sort -n|logger -t DEBUG -f -" and standard out to go through (... Other pipeline)?

Re: Four features that justify a new Unix shell

#50

Post by quotemstr »

oblio wrote: post #48
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 is incompatible with bash...

Every shell that changes how quoting works is incompatible with bash
Post reply on HN