Live data from Hacker News

Why Create a New Unix Shell?

oilshell.org

31–40 of 298 posts

Re: Why Create a New Unix Shell?

#31
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 isn't a new kid on the block. Both it and bash are actually about the same age: 28 years:

https://en.wikipedia.org/wiki/Bash_%28Unix_shell%29

https://en.wikipedia.org/wiki/Z_shell

Re: Why Create a New Unix Shell?

#32

> Shouldn't we discourage people from writing shell scripts? ...people frequently ask this? Tip #21 of "The Pragmatic Programmer" states: "Use the Power of Command Shells."

The last time an OSH article was posted, the top comment was that someone should submit a patch to Bash that makes it refuse to work for scripts longer than 50 lines. It's a strong sentiment that keeps getting repeated (I don't agree wit it).

Re: Why Create a New Unix Shell?

#36

After using fish for 3 years, I'm finding there is very little reason to have my login shell maintain backwards compatibility with bash. The only time I run into issues is when a command expects manipulate environment variables via bash syntax. I think the fish documentation WRT to scripting could be much better, but the language is more elegant than bash or PowerShell IMHO.

Non-bash compliant shells suck from the Google, copy, and it works perspective. I even shy away from using zsh because most setups assume bash.

Just launch a subshell and problem solved. I switch between zsh, bash, cmd, powershell quite frequently.

Re: Why Create a New Unix Shell?

#37
post #4

I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2. In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?

The few times I tried to de shell like things in Python, the absolute pain of actually running commands and getting to their output might be part of the reason.

What is A=$(cmd) in bash is an absolute pain in python.

Re: Why Create a New Unix Shell?

#39
post #24

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…

> consider these two groups of shell users:

> 1. People who use shell to type a few commands here and there.

> 2. People who write scripts, which may get into the hundreds or even thousands of lines.

> Oil is aimed at group 2. If you're in group 1, there's admittedly no reason to use it right now.

From my perspective, fish is basically the opposite of oil in that it mainly targets group 1 (admittedly I'm biased in that I rarely write shell scripts at all). IME fish scripts as a direct replacement for bash scripts are pretty rare, but that doesn't mean it's not a success if it's aimed at interactive use.

Re: Why Create a New Unix Shell?

#40
post #24

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…

It's an entrenched network effect. There's a lot of existing scripts written targeting POSIX shells, and there's an incentive to have all your distro maintenance scripts written in one language if possible.

If you want to switch your existing distro scripts to fish, you need to rewrite a lot of stuff. If you want to start a new distro, "it's written in fish!" isn't a terribly compelling selling point, since I don't think anyone is actively picking distros based on their tooling language.

For the general devops case, there's a lot of existing example code out there for bash scripts, and far less for fish. "How do I do X in bash?" is probably going to get you a decent example on Stack Overflow. Devops (I feel) cares a bit more about the installed-everywhere thing, and fish isn't a standard part of most distros.

Oil having a goal of being completely sh/bash compatible gives it much greater odds of something like Debian switching to it, since it wouldn't carry huge technical debt along with it.

Post reply on HN