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

41–50 of 298 posts

Re: Why Create a New Unix Shell?

#41

Post by okdana »

zapita wrote: post #10

Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.

>Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.

zsh and fish don't really belong in the same comparison IMO.

zsh is, like bash, a ksh-like shell with a Bourne-style grammar. Obviously it depends on the exact use case, but in practice, for basic scripting purposes, it is almost a super-set of bash, and it provides several emulation options (like sh_word_split) specifically designed to increase compatibility with POSIX and with bash in particular. It even provides shims to support bash completion functions. (It is fair to point out that, even with all the emulation stuff enabled, it's still not completely bash-compatible, nor POSIX-compliant. It's close enough that the changes required are usually extremely trivial, though.)

fish on the other hand has its own completely different grammar and makes no attempt to provide POSIX/ksh/bash compatibility at all.

Re: Why Create a New Unix Shell?

#42

Post by yjftsjthsd-h »

jamesgeck0 wrote: post #27
yjftsjthsd-h wrote: post #18

Earlier quoted context omitted.

If you use the same shell interactively as you script in, then you only have to learn the one language.

Except Oil has both POSIX compatibility and Oil. It's not much difference from Fish, where you can largely ignore the built-in scripting language and just write bash scripts if you'd like.

Yeah, with oil I agree. It appears that fish is sometimes incompatible, though; there's a comment down thread about 'Foo=bar baz' working differently, and I have actually used that interactively.

Re: Why Create a New Unix Shell?

#43

Post by delinka »

chubot wrote: post #24
ComputerGuru wrote: post #3

Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…

(author here) Hm I've tried fish, and it seems very nice for interactive use. However I don't see it being used AT ALL for the cloud/linux use case? Those are the cases where you tend to get 1000+ lines of shell scripts. For example, I mention Kubernetes/Docker/Chef, and I've never seen fish in that space. I also don't know of any Linux distro that uses fish as their foundation -- they all appear to use a POSIX shell…

First, I think it's a case of momentum. All the scripts are written in shells that are distributed by default in most distros. sh, bash, etc. I write lots of scripts for fish, and I can't convince my co-workers to install fish to run my scripts. They already have bash, they already know bash, etc.

Second, I was recently chided by another fish user for writing fish scripts: "you're using it wrong" was the sentiment. The argument was it's a shell intended to be interactive, but extendable. I don't know how pervasive this line of thinking is, but who's going to learn all about their shell if they're not supposed to write scripts in its language?

Re: Why Create a New Unix Shell?

#46

Post by 0xdeadbeefbabe »

fusiongyro wrote: post #12
0xdeadbeefbabe wrote: post #6

Earlier quoted context omitted.

Do you have anything to say about rc https://9fans.github.io/plan9port/man/man1/rc.html ?

If you like rc, do you like es? http://wryun.github.io/es-shell/

I don't know. I don't like installing new things on servers in general.

Re: Why Create a New Unix Shell?

#48

Post by aspaceman »

LukeShu wrote: post #29
aspaceman wrote: post #15

Earlier quoted context omitted.

Why do people care about "COMPATIBILITY" so much w.r.t. shells? It's so easy to use other shells to run your script. > /bin/bash your_script.sh And if your script is written with bash in mind, use a shebang: > #! /bin/bash And it will work perfectly fine on fish. As long as I have a bash binary, why do I need COMPATIBILITY?

Why do people care about "COMPATIBILITY" so much w.r.t. C compilers? It's so easy to use other compilers to build your program. > CC=gcc make And if your program is written with gcc in mind, put that in the Makefile: > CC ?= gcc And it will work perfectly fine on LLVM systems. As long as I have a gcc binary, why do I need COMPATIBILITY? ---- A big part of the long-term objectives of OSH is that it provides a way to m…

I'm very confused by your analogy. In the same way that I can hold onto a binary for /bin/bash, I can do the same for gcc-4.7 or whatever. If your software depends on a very specific version to remain compatible, you just keep that thing around which is precisely what the CC env variable is for. Eventually, you'll want to add / change / or update that software, and that's where it's nice that updated versions remain compatible so you don't have to rewrite everything in your codebase.

But a shell script is a script, not a codebase - they're written for one-off scenarios in very specific environments. I imagine that some folks have very large, complicated systems that depend on many bash scripts. But in such a case one can still use fish to just execute the bash scripts and pipe the output around as needed. If you have a single, large bash script that does some really complicated stuff, you can begin porting it by separating it into smaller scripts, calling those from a modern scripting language like Python and rewriting aspects of the process as you go.

A C or C++ codebase is in no way equivalent to a bash and scripting codebase since C and C++ are not nearly as easy to call from different versions - you would have to split up your build process across different versions of a compiler and build a library to accomplish the same thing.

Re: Why Create a New Unix Shell?

#49

Post by simias »

The idea to use a real programming language as a shell is a common one but I'm not sure it's really a problem that can be solved without reworking the kernel interface. Whatever you do pipes will still be byte streams, error handling will always be using integer return values, you'll always have stdin, stdout and stderr, job control and signal handling will always work pretty much the same way. The kernel interface exposes an interface, the userland app expect the shell to behave in the certain way, there's not a lot of wiggle room to make things differently in between the two.

Not that the POSIX-like shell syntax is not all sorts of clunky and odd but I almost consider it a feature, it's a deterrent to force you to move to a "real" scripting language when the concepts become too complex to express in a shell script.

Re: Why Create a New Unix Shell?

#50

Post by z3t4 »

I spent the day making a virtual terminal ... I think the terminal is an unnecessary layer. All program UI is limited by this 40+ year old technology that is the terminal. Instead of making a new shell, make a shell + new user-interface.
Post reply on HN