Why Create a New Unix Shell? • Hacker News Board

Re: Why Create a New Unix Shell?

#131

Post by chubot » Wed, Jan 31, 2018, 11:06 PM UTC

nickez wrote: post #116

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…

What is your take on Ion? https://doc.redox-os.org/ion-manual

Ion looks great, but its goals are different -- most importantly, it doesn't provide an upgrade path from bash. (This is also the biggest difference between Oil and fish, Oil and Elvish, etc.)

I talked with the authors of Ion on github almost a year ago. Ion was influenced by Oil, in particular this post:

http://www.oilshell.org/blog/2016/11/06.html

Re: Why Create a New Unix Shell?

#132

Post by JepZ » Wed, Jan 31, 2018, 11:07 PM UTC

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 software set' across platforms. So after decades we finally have a shell which is available on most operating systems, but how long will it take before Microsoft, Apple, Oracle, etc. will adopt a new shell?

So why don't the large OS corporations form a consortium to define something like a 'cross platform run time environment' standard (maybe together with the Linux Foundation and some BSD guys?). I mean its not so much about which shell someone prefers, but more about a common set of interpreters and maybe tool kits. And even more than that it is not about the state but the process/progress.

What do you think, do we need such a process or is there another way to solve the cross platform dilemma?

Re: Why Create a New Unix Shell?

#133

Post by anderspitman » Wed, Jan 31, 2018, 11:19 PM UTC

Love it. I think there's plenty of room for innovation in this space. I'm currently in the process of porting a ~700 line bash script (I didn't write it) to Python. Although longterm I think this will be much better for the project, there are still tradeoffs. There are some things that are just so easy to express in shell language, like composing transformations via pipes. Sure, python can do it, but it feels clunky in comparison to me. I would love to see a language like python (including package ecosystem) written with shell use as a first-class citizen.

Re: Why Create a New Unix Shell?

#134

Post by webreac » Wed, Jan 31, 2018, 11:20 PM UTC

JepZ wrote: 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…

bash is good enough for launching commands and short scripts. When you want to manipulate data that may contain special characters or write not trivial algorithms, it becomes insane. I think it is a feature. It indicates that bash is not the good tool for that. bash, sed, awk are excellent tools. I know all the basic stuff about them and I know when it becomes tricky. When it becomes tricky, I switch to python or perl.

Re: Why Create a New Unix Shell?

#135

Post by tankenmate » Wed, Jan 31, 2018, 11:20 PM UTC

chubot wrote: post #109

cestith wrote: post #68

In your FAQ you decry Perl as having no ability to redirect around other programs. Yet you don't explain how any of the following fail to meet those needs.: * http://perldoc.perl.org/functions/open.html * http://perldoc.perl.org/IPC/Open2.html * http://perldoc.perl.org/IPC/Open3.html * http://search.cpan.org/~odc/IPC-Open2-Simple-0.01/lib/IPC/Op... * http://search.cpan.org/~exodist/Child-0.013/lib/Child.pm * http://s…

Can you show me some code? How do you write this in Perl? f() { echo -- ls / echo -- } f > out.txt f | wc -l

Here is probably the simplest answer, it's not totally correct but it's the shortest answer that fits the main criteria.

  #!/usr/bin/perl
  
  use strict;
  
  sub f
  {
    my $outputFH=shift;
  
    print $outputFH "--\n";
    open(my $lsFH,"ls /|") or die("pipe ls: $?");
    print $outputFH ();
    close($lsFH);
    print $outputFH "--\n";
  }
  
  open(my $outTxtFH,">","out.txt") or die("open: out.txt:$?");
  f($outTxtFH);
  close($outTxtFH);
  
  open(my $wcFH,"|wc -l") or die("pipe wc: $?");
  f($wcFH);
  close($wcFH);

Re: Why Create a New Unix Shell?

#136

Post by JepZ » Wed, Jan 31, 2018, 11:25 PM UTC

@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 parallelism without the ability to artificially limit the number of parallel executions is often useless.

Re: Why Create a New Unix Shell?

#137

Post by rollcat » Wed, Jan 31, 2018, 11:27 PM UTC

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

> 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 actual WM is written in Lua. If you'd start with an empty init file, you'd have a moderately sized side-project on your hands to put something usable together. But if you'd start from the stock rc, there's a world of endless tweaking and customisation waiting for you...

Watch out, both Emacs and Awesome are rabbit holes.

Re: Why Create a New Unix Shell?

#138

Post by mschuster91 » Wed, Jan 31, 2018, 11:31 PM UTC

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…

> 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 may or may not barf on encountering any of said things...

Re: Why Create a New Unix Shell?

#139

Post by donatj » Wed, Jan 31, 2018, 11:32 PM UTC

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

Re: Why Create a New Unix Shell?

#140

Post by devit » Wed, Jan 31, 2018, 11:37 PM UTC

Seems an interesting idea, but it's implemented in Python, which means it will never replace bash and probably not achieve any significant adoption unless they rewrite it in Rust first (which they should have written it in to begin with since they started in 2016).

The reasons for that are that shells must start very quickly (due to subshells, local ssh, etc.), be fast, have no complex dependencies since they are used to recover broken systems, be portable but also with full support for OS semantics and be written in a language that allows rapid development of robust software, none of which Python does well.