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

91–100 of 298 posts

Re: Why Create a New Unix Shell?

#91

Post by mindcrime »

Osiris wrote: post #73
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…

fish-shell is the first thing I install on any *nix box I work on, including macOS, VPS servers, desktop (Ubuntu), and even Windows Subsystem for Linux. The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. I also find the scripting language more straight-forward.

The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history.

Doesn't bash have that same feature? Or is there some subtle difference between what you're describing and what bash does?

Re: Why Create a New Unix Shell?

#92

Post by dflock »

Osiris wrote: post #73
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…

fish-shell is the first thing I install on any *nix box I work on, including macOS, VPS servers, desktop (Ubuntu), and even Windows Subsystem for Linux. The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history. I also find the scripting language more straight-forward.

> The feature I use the most is automatic history search by typing part of a command and hitting UP to search the history.

This is available in bash/sh by setting this in your ~/.inputrc file:

  "\e[A": history-search-backward
  "\e[B": history-search-forward
  "\e[C": forward-char
  "\e[D": backward-char

Re: Why Create a New Unix Shell?

#93

Post by kakarot »

arghwhat wrote: post #77
chubot wrote: post #24

Earlier quoted context omitted.

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

Back when I started programming, I wrote 1000+ lines of shell scripts. Now, I quite seriously believe that a 1000 line shell script only exists out of error. I still occasionally end up doing 2-300 line dense shell scripts, but not without feeling very dirty along the way. Either split into small, simple shell scripts (which is fine), or a different language. In the cross platform build pipeline at work, I keep a str…

If your script is over 80-120 lines, it's time for modularization. No sane person writes 1000 line scripts, and the fact that the Oil author uses such a scenario as a reason to use their shell is very disconcerting about the quality of code and I wouldn't touch Oil with a ten-foot pole.

Re: Why Create a New Unix Shell?

#94

Post by laumars »

djsumdog wrote: post #59
laumars wrote: post #9

Earlier quoted context omitted.

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

Thank you and you're absolutely right about the process of creating a shell being a great learning tool! I've learned so much writing murex - even some stuff that I assumed I knew I quickly discovered my understanding wasn't quite right.

Re: Why Create a New Unix Shell?

#95

Post by chubot »

hrktb wrote: post #53
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?

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.

Right, the system() function in C, which PHP probably uses, and is os.system() in Python, is DEFINED to run /bin/sh. You never know when a program might call it (although I agree it is almost always bad practice to use it -- use fork/exec instead.)

So basically you should never make /bin/sh fish, because then you will no longer have a Unix system (according to POSIX).

Re: Why Create a New Unix Shell?

#96

Post by jernfrost »

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.

Interesting seeing so many fish fans. I absolutely love fish. It makes my everyday shell usage so much nicer. But it seems like a totally unknown shell to most people. I never see anybody else use it at any job I've had.

I did use fish a bit as a script language, but I decided for anything of any size I much prefer Julia. For typical file system navigation, fish is better, but Julia is actually pretty decent as a shell, despite being a real language. So writing shell scripts in it is pretty nice.

In the beginning I wrote separate programs executed from fish shell. But now I just fire up Julia as a shell and run functions directly there interactively.

Re: Why Create a New Unix Shell?

#97

Post by [deleted] »

StreamBright wrote: post #79
chubot wrote: post #24

Earlier quoted context omitted.

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

One question though: Do you really need 1000+ lines of shell scripts? I almost have 20 years with shell scripting and I still have the rule of not writing longer than 1-2 page shell scripts and use something else for longer projects or break it down to much smaller chunks and invoke the parts with a main.sh. Fish is a for making software engineering and system administration easier by having functionality like comman…

[deleted]

Re: Why Create a New Unix Shell?

#98

Post by chubot »

kevlar1818 wrote: post #71

> However, Python and Ruby aren't good shell replacements in general. Shell is a domain-specific language for dealing with concurrent processes and the file system. But Python and Ruby have too much abstraction over these concepts, sometimes in the name of portability (e.g. to Windows). They hide what's really going on. Excellently put. POSIX shell languages have fantastic capabilities you just can't get in most othe…

Thanks, and you have put it very well too. As I've learned from many of these threads [1], there most certainly is a narrative that shell scripts are dangerous and impossible to maintain. People are really angry about it!

And of course I agree with that! That's the whole reason for Oil.

[1] http://www.oilshell.org/blog/2018/01/31.html

Re: Why Create a New Unix Shell?

#99

Post by chubot »

dmix wrote: post #25

I checked out Oil previously which looks nice but more of an incremental improvement over Fish/ZSH rather than a significant evolution (it may have changed since then, this was last year). Im most excited about Elvish shell and the language that's being developed around it. The shell is built with Go and feels super fast compared to my plugin-heavy ZSH. The language design is quite nice too but still very alpha. Look…

FWIW, OSH is the incremental improvement, and Oil is the new language (explained in the intro to this post.)

Re: Why Create a New Unix Shell?

#100

Post by chubot »

z3t4 wrote: post #50

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.

I agree, but the first step is to make a shell. I imagine it will be like Vi or Emacs -- it can write to a terminal, or have its own UI.

I have been keeping a wiki page:

https://github.com/oilshell/oil/wiki/Interactive-Shell

Although honestly I won't get to any of this in the near future.

Post reply on HN