Live data from Hacker News

Why Create a New Unix Shell?

oilshell.org

211–220 of 298 posts

Re: Why Create a New Unix Shell?

#211
post #160

Earlier quoted context omitted.

FWIW I have your project on my wiki page :) https://github.com/oilshell/oil/wiki/ExternalResources I guess what you mean by embedded is that it should be an embedded DSL in a full-fledged programming language? I don't quite agree, since there are at least 20 projects like that on the wiki page, none of which is popular. Probably the most popular one is eshell, in Emacs Lisp? But if there's something I don't know abou…

Yes, actually I've looked over all the shells on that wiki page. I think most of them haven't taken off because they either their host language has been poor or unpopular, their design or implementation wasn't great, or they haven't really solved the right problem. I think the idea of embedding a shell into a general-purpose language still has a lot of merit. Most of those projects trying to embed a shell DSL into a…

OK great, glad you have made use of the page. We had an "alternative shells" thread about a year ago between the authors of Elvish, NGS, Oh, and mash. Those were the main active/nascent shells I could find.

It might be time to start that again to see what ideas people have and what has changed. If you're interested e-mail me at andy@oilshell.org.

I'm also interested in the Shill shell, which as I understand was written in Racket, and then somehow they moved away from Racket? I'm not sure. I think it was because of the runtime. I also saw some efforts to move Racket to Chez Scheme.

I very much like Racket as an idea -- a meta language -- but I haven't gotten a chance to play with it too much.

And I did experiment with femtolisp as a basis for Oil -- the lisp used to bootstrap Julia -- but I decided against it.

Re: Why Create a New Unix Shell?

#212
post #136

@chubot: There is one use-case I come across every once in a while: https://stackoverflow.com/questions/356100/how-to-wait-in-ba... So whenever you want to do things in parallel there is probably a limit to the number of processes you would like to execute in parallel (e.g. the famous compiler limit formula: number of CPU cores +1). It would be great if Oil could support such a use-case out of the box, as easy parall…

Absolutely. In fact, the bash manual explicitly refers to GNU parallel for this use case!

I use xargs -P all over the Oil codebase, which does what you want. The trick is to end the file with "$@", and then invoke xargs -P 4 -- $0 my-func.

That way xargs can run arbitrary shell functions, not just something like sh -c "..." ! I'm going to write a blog post about this. I also do this with find -exec $0 myfunc ';'

https://github.com/oilshell/oil/blob/master/test/spec-runner...

However I think Oil will have something built-in to make this parallel process more friendly. I will probably implement xargs so it can run my own shell scripts without GNU xargs, but then add a nicer syntax. (Probably "each", since that's what xargs really does.)

This gets into your other question about standard utils, which I'll answer now. Short answer: yes I would like something like that, it's just a matter of development time and priorities. I agree with the problem you point out.

Re: Why Create a New Unix Shell?

#213
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

IIRC, Python performance is better than than bash.

Re: Why Create a New Unix Shell?

#214
post #132

Sounds pretty cool and everybody who had to learn bash scripting at some point understands why we need a sane language (my favorite are misplaced spaces in if statements...; Disclaimer: I do and love bash scripting but while the language has cool concepts, some things are just broken by design). Nevertheless, there is one piece in this puzzle I am missing. There does not seem to be a process which manages the 'core s…

I've been thinking about related issues.

Probably the first cut will be an "app bundle" format for Oil + busybox + arbitrary user utilities.

I'm more interested in the subset of busybox that is PORTABLE. busybox doesn't run on BSDs, because a lot of it is tied to the Linux kernel. It's more for embedded Linux.

I actually worked on the toybox project around when starting Oil (toybox is the "busybox" on Android, started by the former busybox maintainer Rob Landley.)

So I don't want to necessarily create another package manager, which is sort of implied by your question (?). For shell, the package manager is traditionally the system one -- "apt-get" on Debian, maybe homebrew on Mac, etc.

But I definitely want to solve the dependency problem, and I think the best way to do that is through some kind of support for app bundles. Of course you can also create a container image if you like.

Re: Why Create a New Unix Shell?

#215
post #139

I was with the guy right up until the bile laden PHP hated started coming in as a justification.

(author here) I didn't intend to criticize PHP, and I don't think I did.

I said that you can't convince people not to use bash or PHP by writing posts on the Internet, which is true.

I also said that Facebook is replacing PHP, which is true. That's not a criticism of PHP. The fact that huge companies like Yahoo and Facebook can be started with PHP is amazing.

I think PHP is a good analogy for bash. It gets the core things right, and it gets a ton of work done. I like languages you can get work done in! That's why I use bash.

But both languages also evolved a lot of warts. That's inevitable when you have so many users. They have diverse needs, and you need to preserve backward compatibility, which leads to an awkward evolution.

Re: Why Create a New Unix Shell?

#216
post #149

Earlier quoted context omitted.

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…

Okay, bracketed paste does not help against attacks.

Re: Why Create a New Unix Shell?

#218

Earlier quoted context omitted.

Manipulating processes, exit codes and output is idiomatic in shells and that's where they shine. I totally agree with you. In a general purpose programming language there's a lot of overhead for doing the same things. For maintainability, there are now linters for shell languages that can help making the job easier.

> linters for shell languages Obligatory in case anyone hasn't seen it: https://www.shellcheck.net/ Works as a web app or local tool.

thanks for this

Re: Why Create a New Unix Shell?

#219
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 just have to say, that's a beautiful name for a shell.

Thank you. I found choosing a name for the shell harder than writing any of the code

Re: Why Create a New Unix Shell?

#220

Earlier quoted context omitted.

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

> an IDE based on the language it was written in I recommend Emacs. Maybe not as a daily driver (it's a matter of preference), but for the experience. I recommend at least a month with it, make sure to write some original Lisp code for your customisations. (You WILL end up customizing it, the defaults are crap.) > or a window manager I recommend Awesome. The core is in C, but that's basically the low-level stuff, the…

At some point I realized that I wasted months in those rabbit holes customizing and tweaking shell configs, window managers and Emacs. Any gain in productivity (which may not even be there as it is rather subjective) was not able to offset it. So I stopped it. These days I just use Gnome Shell with a single extension to fix something that I cannot get used at all, simple bash config to setup environment for development with no customization on shell behavior, and a programming editor that mostly matches my taste. On a new machine I can finish all customization within 5 minutes and forget about it.

I even started to suspect that an easy customization of a tool can be a bad sign. It is almost like developers delegates all usability issues to the end user making the default case really bad.

Post reply on HN