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

51–60 of 298 posts

Re: Why Create a New Unix Shell?

#51

Post by zokier »

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…

> Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use).

Elvish is pretty nifty, but the biggest failing point to me is that the fancy rich pipelines really work just for in-process stuff, which for me kinda loses the point of being a shell. Of course I do realize that rich (polyglot) interprocess pipelines is a difficult problem; some might say a pipedream.

Re: Why Create a New Unix Shell?

#52

Post by wryun »

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

Have you tried plumbum or sh.py?

They work well, if a bit magically, until you need to background a process.

Re: Why Create a New Unix Shell?

#53

Post by hrktb »

aspaceman wrote: post #15
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.

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?

One of the werid cases with fish as default shell is scripts and programs that expect bash when executing “system” commands. For instance a php or Java program running shell commands.

Having bash compatibility is a quality of life feature, no need to debug all the werid cases where it breaks for purely syntax reasons.

Re: Why Create a New Unix Shell?

#54

Post by oblio »

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…

Totally off topic: great blog. I was reading the archives these days, they’re awesome ;)

Re: Why Create a New Unix Shell?

#55

Post by wutbrodo »

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

That was my main pain initially after I finally switched away from writing my scripts in Bash, but it actually turned out to be pretty easy. I wrote a quick helper function that does 99% of what I need:

def _call(cmd_str): return subprocess.check_output(shlex.split(cmd_str)).decode("utf-8")

Definitely a verbose monstrosity compared to doing it in bash, but more than worth avoiding the garbage fire that is Bash. And it only works for simple cases

Re: Why Create a New Unix Shell?

#57

Post by bodyfour »

jhillyerd wrote: post #2

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.

I sort of agree that there isn't any strong reason for an interactive shell to have 100% bash compatibility. However, when I tried to convert to using fish I found my muscle-memory used too many simple history substitutions like "!!" and "!$" (which actually pre-date bash; they arrived with csh 40 years ago!) which were missing. Ultimately I gave up and went back to bash.

It sort of is an "uncanny valley" for a text interface. It feels close enough to a traditional UNIX shell that I start to interact with it like one... but has enough differences that I found myself constantly tripping over them.

Re: Why Create a New Unix Shell?

#58

Post by chubot »

oleks wrote: post #35

Why is Oil implemented in Python? IMO Python is a terrible language for writing programming languages.

I will address that in part 2 of the FAQ, but the short answer is:

1) I prototyped it in Python; the dependency on the Python interpreter will be removed [1]

2) Oil went through many implementation languages, and one incarnation was 2000-3000 lines of C++. But I realized I would NEVER finish that way. The goal is to be compatible with bash, which is a tall order.

3) Oil is heavily metaprogrammed. It's only 16K lines of Python, compared to 160K lines of bash, and it can run some of the most complex bash programs out there. [2]

It's more accurate to say Oil is written in Python + ASDL [3], i.e. somewhat in the style of ML.

[1] https://news.ycombinator.com/item?id=16277358

[2] http://www.oilshell.org/blog/2018/01/15.html

[3] http://www.oilshell.org/blog/tags.html?tag=ASDL#ASDL

Re: Why Create a New Unix Shell?

#59

Post by djsumdog »

laumars wrote: post #9
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…

Shameless self promotion but I'm writing my own shell, murex, as well[1] The goals of mine are akin to Fish in terms of REPL use but with a greater emphasis on scripting. Like Fish, murex also does man page parsing (in fact I wrote mine before realising Fish did the same), but unlike fish autocompletions can be defined by a flat JSON file (much like Terraform) as well as dynamically with code. Currently I'm working o…

I messed around with oil earlier this week when I saw this posted elsewhere and I've been a fish user for about 4 years now.

I'll have to give yours a spin too. I'm glad there's a lot of shell innovation right now. I'm all for breaking posix shell standards and creating things that are way more usable. Fish's prompt customization, functions, highlighting, completion and searching are pretty amazing.

I realize a lot of these little projects will come and go. No matter what, they're great learning tools for the creators/developers, exploring what it takes to make an interactive shell.

Still, I hope we see more stuff like fish come out (and make no mistake, fish took a lot of years and a lot of devs. In the early days my instance would crash every once in a while in ways I couldn't easily reproduce). It's great that we're finally getting away from the traditional bash/zsh/ksh stuff and into newer shells that make coding and navigation easier.

Re: Why Create a New Unix Shell?

#60

Post by djsumdog »

bodyfour wrote: post #57
jhillyerd wrote: post #2

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.

I sort of agree that there isn't any strong reason for an interactive shell to have 100% bash compatibility. However, when I tried to convert to using fish I found my muscle-memory used too many simple history substitutions like "!!" and "!$" (which actually pre-date bash; they arrived with csh 40 years ago!) which were missing. Ultimately I gave up and went back to bash. It sort of is an "uncanny valley" for a text…

It was difficult to implement !! and !$ in fish (I rarely actually used them in bash, so it wasn't an issue for me) and I know others who found that annoying. However if you dig around, there are a couple of solutions on Stack Overflow and blog posts that add in that functionality using plugins or functions. It's not exactly the same, but some of them work pretty well.
Post reply on HN