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

101–110 of 298 posts

Re: Why Create a New Unix Shell?

#101

Post by kelnos »

kakarot wrote: post #93
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…

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.

Re: Why Create a New Unix Shell?

#102

Post by [deleted] »

djsumdog wrote: post #62
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.

That's just lazy programming, and if anything, we should have more incompatible shells so that developers will start to write their programs to stop shelling out and run individual programs, or if they do shell out, actually declare the shell you're using at that point and don't assume it will be sh compatible.

[deleted]

Re: Why Create a New Unix Shell?

#103

Post by effie »

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…

The whole point of these projects is to evolve the shell, go beyond the current bash standard to make the work with the shell more fun and more productive. Unix may seem to have limited default interfaces, but this was by design - the idea was, the programmer/user knows much better what he needs so let him build it. The system's role was shaped to provide robust universal mechanisms. Also, the current standard shell is very limited when compared to even existing unix interfaces. For example, the kernel provides select/poll system calls but standard shell has no facility to use them, so simultaneous processing of two or more data streams without blocking is not currently possible. A new shell could finally provide them.

Re: Why Create a New Unix Shell?

#104

Post by chubot »

kakarot wrote: post #93
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…

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.

Re: Why Create a New Unix Shell?

#105

Post by ComputerGuru »

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…

I agree that the age of 1000+ lines of shell script code should be over; just replace the shebang and use whatever other language you like instead. Unless you need something dependency-free, compilation-free, and portable, then God help you because sh it is.

It's funny though, after decades of shying away from them I've now gone full circle and embraced Makefiles once more. Perhaps it's the cleanness of the bmake/pmake extensions as compared to those of GNU Make, but the determinism, zero dependencies (no CMake or meson and its python baggage), automatic parallelization, and strict error handling call to me each time I have to write mission critical "glue code" that must. just. work.

Re: Why Create a New Unix Shell?

#106

Post by chubot »

StreamBright wrote: post #79
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…

One question though: Do you really need 1000+ lines of shell scripts? I almost have 20 years with shell scripting and I still have the rule of not writing longer than 1-2 page shell scripts and use something else for longer projects or break it down to much smaller chunks and invoke the parts with a main.sh. Fish is a for making software engineering and system administration easier by having functionality like comman…

See https://news.ycombinator.com/item?id=16278141

Re: Why Create a New Unix Shell?

#107

Post by oblio »

chubot wrote: post #90
oblio wrote: post #54

Earlier quoted context omitted.

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)

My two main comments would be:

1. Keep up the great work (both oil and the blog!) Both seem fun :)

2. Reading your blog really shows that despite the great ideas, shell languages come from an age where computing was still in its infancy. We’re now approaching our teen years, but we’re still ahead of infants. So many awkward design decisions and organic evolutions. A shame that replacing POSIX at this point is a gargantuan undertaking.

Re: Why Create a New Unix Shell?

#108

Post by msla »

aerique wrote: post #83
delinka wrote: post #43

Earlier quoted context omitted.

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?

The point is the compose-save-edit cycle: Compose the script in the shell, save it to a file, and then, maybe, edit it to add better argument handling or support for corner cases you didn't consider in the interactive environment.

Re: Why Create a New Unix Shell?

#109

Post by chubot »

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

Re: Why Create a New Unix Shell?

#110

Post by racer-v »

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…

> 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 have heard things like, "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." Forcing yourself to always use the lowest common denominator of software is not a fun path.

Post reply on HN