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

81–90 of 298 posts

Re: Why Create a New Unix Shell?

#81

Post by ViViDboarder »

askz wrote: post #65
djsumdog wrote: post #60

Earlier quoted context omitted.

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.

I use !! maybe ten times per day. !$ can be implemented in your PS1 easily.

I used to. Now I just Ctrl-P.

Re: Why Create a New Unix Shell?

#82

Post by Symmetry »

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.

Personally I leave bash as my login shell and just set my terminal emulator to launch fish on startup.

Re: Why Create a New Unix Shell?

#83

Post by aerique »

delinka wrote: post #43
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…

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

I've been using fish for years but I never write scripts in it. What's the point?

There's sh which is the most portable. Why write scripts in anything else but an actual programming language when things get more complex?

Re: Why Create a New Unix Shell?

#84

Post by LukeShu »

aspaceman wrote: post #48
LukeShu wrote: post #29

Earlier quoted context omitted.

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…

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

Exactly? What you just said is true for CC and SHELL; I'm not sure what is confusing.

> But a shell script is a script, not a codebase - they're written for one-off scenarios in very specific environments.

Ahh, there it is. IMO, a big part of the reason why many people think that people shouldn't write shell scripts is that they've only had to deal with shell scripts written by people who didn't treat it as a real codebase.

It's hard to say what private codebases are doing but:

- Docker, which is expected to run in many different environments, has thousands of lines of shell. That isn't one-off, and isn't for a specific environment.

- Most GNU/Linux distros can generally be thought of of many separate upstream packages glued together by many thousands (if not millions) of lines of shell. It might be expected to run in a fairly specific environment, but it isn't one off, and is massive enough, I'd have a hard time not treating it as a codebase.

> ... you can begin porting it by separating it into smaller [programs], calling those ...

> 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

C is very easy to call from different versions, the ABI(s) has been very stable over the years (unfortunately, this isn't as true for C++). Just say `myobj.o: private CC=gcc-4.7` or whatever compiler is needed for myobj.c, to set the compiler for just that object.

You seem to be saying "I don't need C (bash) compatibility, I just need an FFI that makes it easy to call C (bash) code."

C/C++ and Bash/OSH are different, but not that different.

Re: Why Create a New Unix Shell?

#85

Post by ViViDboarder »

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.

Same. The assumption that both types of users need to have their use case solved by the same language is foreign to me.

I use Fish as my shell, but I do scripting with Bash. There’s nothing that prevents you from doing so unless you’re sourcing a file.

Re: Why Create a New Unix Shell?

#86

Post by jernfrost »

I essentially solved these problems with fish shell and Julia programming language.

For all sorts of interactive stuff I use fish, because it works the way you want for the most common tasks. I can use it to really quickly match and get back previous statements or do a completion.

Also much easier to configure and grok than bash, because it has saner syntax and is a simpler shell language.

However when writing shell scripts I use a real language like Julia. It integrates very well with the shell world so I don't find it problematic to do this. It is very easy to read output from processes and pipe stuff. Much nicer than say Python or Ruby.

You got built in syntax to deal with shell stuff, but then didn't make it crazy so you end up with a mess like perl. Julia is actually a very clean and nice language. Which also happens to blistering fast and have LISP style macros.

Re: Why Create a New Unix Shell?

#87

Post by vapemaster »

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.

Use xonsh!

Xonsh is an awesome fishy she'll that's a Python superset. $() is built right in.

Re: Why Create a New Unix Shell?

#88

Post by laumars »

simias wrote: post #49

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

I've been considering this problem myself and I believe there are ways to get around the limitations you've described. It's not pretty (from an ideological perspective) but it does work and is mostly invisible to the end user. The problem is when users hit those weird edge cases where the hack becomes visible. :-/

Re: Why Create a New Unix Shell?

#89

Post by fusiongyro »

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

Earlier quoted context omitted.

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.

So, bash it is. :)

I love using fish and enjoy scripting with it too, but I'm hampered by this fact as well, and mostly use bash at work when others might see it or have to use it.

Re: Why Create a New Unix Shell?

#90

Post by chubot »

oblio wrote: post #54
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…

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

Thanks! Feel free to comment (with the reddit links at the bottom of each post)
Post reply on HN