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

141–150 of 298 posts

Re: Why Create a New Unix Shell?

#141

Post by racer-v »

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.

Gentoo is basically this. I learned Python by writing .ebuilds (their package format is a short Python script that downloads and builds whatever software you're installing).

Re: Why Create a New Unix Shell?

#142

Post by eikenberry »

kemayo wrote: post #40
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…

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…

The fact that there is the POSIX standard and multiple shells that meet that standard is also a big part of it. If you write in a POSIX compatible shell language you know it can run anywhere. Fish, for example, has no standard and only 1 implementation.

Any new shell that hopes to compete in the systems space will have to be POSIX compliant. At least until there is a new widely adopted shell standard.

Re: Why Create a New Unix Shell?

#143

Post by aplorbust »

This keeps showing up on the front page. No doubt it will have users.

Lets say there are two uses of a shell: 1. interactive and 2. non-interactive (scripting).

Lets imagine the commandline user is learning about her OS. She learns it is heavily reliant on shell scripts to build and (if desired) to automate starting services.

She realises that to understand the OS she will have to learn the shell that the OS developers used for scripting.

Then she realises that if she chooses another shell for interactive use, she will have to learn two shells.

Finally she realises that any script she writes in the "non-interactive/scripting" shell will also run under the interactive one. But not vice versa.

If she only has enough time in life to master one shell, which one should she choose?

Over time I found I really cared more about the scripting aspect of a shell than the interactive facet.

The scripting shell used by the OS authors might be an Almquist derived shell, for instance.

Occasionally the ash Im using gets a new "feature" but not too often. I like that it stays relatively small. The latest "feature" is LINENO.

But I also use a smaller version of this shell with no command line history, no tabcomplete, etc. IMO, there is no better way to learn how to reduce keystrokes. It has led to some creativity in this regard for which I am thankful.

After "mastering" ash, I started using execlineb, pipeline and fdmove. I am starting to use more components of execline and am continually replacing ash scripts with execline scripts for more and more daily work.

I guess we will never see execline on the front page, which I think would be interesting because I would like to hear whatever harsh critique HN can muster.

Seeking a better non-interactive/scripting experience, I have experimented with many other shells over the years, and written simple execve "program launchers", but in this vein, I have not found anything that compares to execline.

The speed gains and resource conservation are obvious, but with the ability to do "Bernstein-chaining" and the option to use djb low-level functions instead of libc, it is a rare type of project.

The speed and cleanliness of the compilation process is, compared to all the other crud one routinely encounters in open source projects, "a thing of beauty". Humble opinion only, but I think others might agree.

Re: Why Create a New Unix Shell?

#144

Post by Macha »

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…

My personal threshold for upgrading from shell to Python is about "I need an if statement".

Re: Why Create a New Unix Shell?

#145

Post by rollcat »

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…

> Forcing yourself to always use the lowest common denominator of software is not a fun path.

Second this. Been there, and back, and there again, and recently back again.

Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk.

If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an occasional session with busybox also helps keep "pure POSIX" skillset fresh. If you're becoming a regular there, it's time to think how to make your dotfiles portable. google.com/search?q=dotfiles

Re: Why Create a New Unix Shell?

#146

Post by hrktb »

chubot wrote: post #95
hrktb wrote: post #53

Earlier quoted context omitted.

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

PHP somewhat takes the user’s login shell, so I guess it’s yet a different system. If it was taking /bin/sh it would have been fine actually.

Re: Why Create a New Unix Shell?

#147

Post by racer-v »

mschuster91 wrote: post #138
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…

> They must be short ( Well, the question is: what do you use as a replacement? For my scripts I tend to pull in some version of PHP as soon as needed. Perl is something that's universally available in anything based on Debian or Ubuntu, but it's a maintenance nightmare, and PHP doesn't care whether I use spaces, tabs or a mixture, or if there are due to any circumstances mixed line endings in a file whereas Python m…

Anything that supports pipes and signals, and is easy to install. I've started using Steel Bank Common Lisp (SBCL) because it's the default implementation used with the Roswell installer.

https://github.com/roswell/roswell

(As a side-note: Perl 5 was really the ideal language for this, by design; we might be in a different world today if it hadn't been derailed by Perl Forever^W 6).

Re: Why Create a New Unix Shell?

#148

Post by throwaway7645 »

Insanity wrote: post #124
toyg wrote: post #113

Earlier quoted context omitted.

> 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

Early Smalltalk and Lisp systems were those langs all the way down. Using emacs with Common Lisp or using Pharo Smalltalk can give you a feel for this, but not exactly the same thing as a Symbolics lisp machine or the Xerox Alto. Alan Kay has a presentation where he shows the entire OS, word processor, networking stuff, IDE, paint programs...etc was an insanely small amount of code and everything was user configurable. I really wish that had caught on more. I really enjoy Linux (although it ain't perfect). Using Windows and trying to interactively do anything with the OS is an exercise in pain and frustration. If someone could build a modern machine with an OS that is like that and had a few basic apps (web browser...etc), I would be quite happy.

Re: Why Create a New Unix Shell?

#149

Post by jraph »

badminton1 wrote: post #128
jhasse wrote: post #34

Earlier quoted context omitted.

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

For 1, my configuration of zsh solves the problem and avoids surprises by marking pasted shell code and letting me review it before running it, even if there are several lines. This is great for just pasting stuff from the internet and adapt as I wish without having to retype the entire thing or use an editor. I think this is a default behavior in oh-my-zsh.

Actually, my zsh config mostly behaves like fish with great completion, syntax coloring and sensible history handling, with zsh syntax which is close to bash. So I can copy paste stuff from the internet and reuse my knowledge from the time I used bash because it was the default, and still leverage the improvements brought by zsh.

I don't understand 2.

For 3, of course you should understand what you run, but I don't want my tools to get in the way. My tools should allow me to do what I want, not prevent me from doing something for technical reasons. This is a question of education. If people want to run something without understanding it, I bet they will type it blindly, if they can't copy paste it. They will just be slower at running things blindly, leading them to a disaster just a bit slower. Please let me not lose my time even more when I cause disasters.

(Yes, true, retyping stuff forces your more to think about it, but I already review the things I paste into my shell)

Re: Why Create a New Unix Shell?

#150

Post by v_lisivka »

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.

In bash, you can type ^R, then text, to search that text in history interactively. Hit ^R again, if you want to see another match of same text. It saves lot of typing.
Post reply on HN