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

121–130 of 298 posts

Re: Why Create a New Unix Shell?

#121

Post by willghatch »

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…

Shell is my favorite domain-specific language. But many (including myself) would argue that domain-specific languages are generally better embedded. Many projects aiming to mixing shell with general purpose languages find a nice embedded DSL for subprocess/pipeline management. Some others find a convenient way to run shell commands or pipelines by mixing grammars and trying to disambiguate them. [Shameless self-promotion] I've been working on a project that aims to not only have a nice DSL for running process pipelines, but focuses on making a syntax for using all functionality of the host language as a command language, called Rash[1]. It is hosted in Racket, and can be embedded in Racket at the module or expression level, and also normal Racket expressions can be embedded in Rash (they can alternate arbitrarily deep). It supports process pipelines, Racket function/object pipelines, and mixes of the two. It's still alpha and has a TODO list a mile long, but I've been using it as my daily driver interactive shell for months and have loved it so far.

[1]: https://github.com/willghatch/racket-rash

Re: Why Create a New Unix Shell?

#122

Post by sethrin »

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…

Bash is flat-out not a scripting language. It is a command language. It does not support typed variables, or named parameters, or any number of basic scripting language features. It technically does not even provide an 'if' construct. It's sufficient as a 'glue layer', and the Unix toolchain is nice, but it provides next to nothing in the way of abstraction, and that's liable to become a problem closer to the 1000 character mark than 1000 lines.

My rough heuristic is, "no more than ten lines, nor more than two variables." Yes, that's short almost to the point of absurdity. The only good thing that one can say about Bash as a scripting language is that it's better than csh. Bash is taken seriously because of its longevity and ubiquity, but it's fundamentally limited in what it can express, and it is quite trivial to exceed those limitations.

Re: Why Create a New Unix Shell?

#123

Post by ake1 »

mindcrime wrote: post #91
Osiris wrote: post #73

Earlier quoted context omitted.

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?

UP in bash swaps the commandline to your previous command, it does not search in your history. either way, please don't move your fingers all the way to your arrow keys for this.

Re: Why Create a New Unix Shell?

#124

Post by Insanity »

toyg wrote: post #113
kemayo wrote: post #40

Earlier quoted context omitted.

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

> I don't think anyone is actively picking distros based on their tooling language. I would use the crap out of a Linux distribution built in python.

yeah I can actually imagine that. like using an IDE based on the language it was written in to extend and tweak it more easily, or a window manager etc..

actually now you mentioned it, barring possible performance issues I'd also like a Python distro

Re: Why Create a New Unix Shell?

#125

Post by chubot »

racer-v wrote: post #110
arghwhat wrote: post #77

Earlier quoted context omitted.

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…

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I…

Yes, absolutely. Oil has a principled representation of the interpreter state, so it should be easy to write a debugger.

(Although note that bash actually has a debugger called bashdb, which I didn't know about until recently, and I've never heard of anyone using it.)

One intermediate step I would like to take is to provide a hook to dump the interpreter state on an error (set -e). Sort of like a "stack trace on steroids".

If anyone is running shell cron jobs in the cloud and would like this, please contact me at andy@oilshell.org.

I want to give people a reason to use OSH -- right now there is really no reason to use it, since it is doing things bash already does. But I think a stack trace + interpreter dump in the cloud (like Sentry and all those services) would be a compelling feature. I'm looking for feedback on that.

Shell scripts have a very small amount of in-process state, so it should be easy to dump every variable in the program.

Also some kind of logging hook might be interesting for cloud use cases.

Re: Why Create a New Unix Shell?

#126

Post by ComputerGuru »

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.

Spin up a virtual machine! (Or an EC2 t2.micro instance, free of charge)

Re: Why Create a New Unix Shell?

#127

Post by kakarot »

chubot wrote: post #104
kakarot wrote: post #93

Earlier quoted context omitted.

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.

Please read the FAQ: http://www.oilshell.org/blog/2018/01/28.html#toc_7 I didn't write those scripts, and you rely on them, whether you know it or not. Do you use Unix? Do you use the cloud? You rely on them. See: https://www.reddit.com/r/linux/comments/7lsajn/oil_shell_03_... Also, shell has functions.

I see. My apologies for being so critical. I agree that POSIX is incomplete and out of date.

However I do think it is a disaster that people can't break up their shell code into more modular components, and there is no excuse for it.

And I especially do not wish to discourage you from trying to reinvent shell, because someone has to do it, but at minimum I don't see myself moving away from my shell for the better part of a decade. Hopefully at that point Oil's community has matured to the point where I feel comfortable trusting it to be stable and free of any critical privilege escalation bugs.

Good luck!

Re: Why Create a New Unix Shell?

#128

Post by badminton1 »

jhasse wrote: post #34
badminton1 wrote: post #21

Earlier quoted context omitted.

That's a great argument for fish.

That you can't?

Why not to copy and paste:

1) what you paste might not be exactly what you copied. i.e: http://thejh.net/misc/website-terminal-copy-paste

2) possible licensing issues

3) it enables cargo cult programming

Re: Why Create a New Unix Shell?

#129

Post by kakarot »

kelnos wrote: post #101
kakarot wrote: post #93

Earlier quoted context omitted.

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.

If that's the case, then there are a lot of insane people out there. I sympathize with your opinion on how things should be (though I may or may not agree), but at the end of the day we need to look at what the reality of the world is , not on the ideal way we think people should be using the tools we already have.

Well to be fair, there are a lot of insane people out there. :-)

Re: Why Create a New Unix Shell?

#130

Post by ComputerGuru »

CGamesPlay wrote: post #20
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.

> The only time I run into issues is when a command expects manipulate environment variables via bash syntax. And in my experience 90% of those are in the form `FOO=bar command` which can be replaced with `env FOO=bar command` and works just fine in fish.

Both support for `&&` and `||` (instead of `and` and `or`) as well as supporting `FOO=bar command` are under consideration for fish 3.0 to ease the migration path. The former is pretty much going to happen, the latter if we get around to it, DV.
Post reply on HN