Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Four features that justify a new Unix shell

oilshell.org

Post reply on HN
Print view View original

71–80 of 185 posts

Re: Four features that justify a new Unix shell

#71

Post by FreshFries »

R0b0t1 wrote: post #66
pierrebai wrote: post #60

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it. Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was lit…

There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live.

I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers.

/rant.

Re: Four features that justify a new Unix shell

#72

Post by theonemind »

R0b0t1 wrote: post #66
pierrebai wrote: post #60

I'm sorry to say to for me, shell scripting has lost. All my scripts are written in Python, which a thin shell script wrapper to launch it. Look at Oil. It tries hard to be bash compatible with optional buy-in to extension. Just use a superior language and give up on shell scripts, that's my advice.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was lit…

A lot of people have a knee-jerk negative reaction to the name perl without understanding that perl chewed up and spit out this particular problem space. You probably don't want to develop your next webapp with a team of perl coders, but the language has its niche.

Re: Four features that justify a new Unix shell

#73

Post by boogies »

coldtea wrote: post #61
boogies wrote: post #40

Earlier quoted context omitted.

> feels a lot more like programming When I want to program a script, I can use a scripting programming language like Python with its object oriented nature. When I want to interactively command my computer I can use a shell like bash or zsh. Do one thing and do it well.

> Do one thing and do it well. That's how we got in today's mess. Do the things people want in a coherent, cohesive, well thought out way - don't combine N independent programs that can barely took to each other with stringly typing and ad-hoc parsing...

Sounds like you’d prefer Python.

Re: Four features that justify a new Unix shell

#74

Post by ska »

boogies wrote: post #73
coldtea wrote: post #61

Earlier quoted context omitted.

> Do one thing and do it well. That's how we got in today's mess. Do the things people want in a coherent, cohesive, well thought out way - don't combine N independent programs that can barely took to each other with stringly typing and ad-hoc parsing...

Sounds like you’d prefer Python.

I don't think you'll find universal agreement that python is "coherent, cohesive, well thought out"...

Re: Four features that justify a new Unix shell

#75

Post by MaikuMori »

7thaccount wrote: post #30
klodolph wrote: post #17

Earlier quoted context omitted.

Agreed... PowerShell is actually interesting and it feels a bit more like you're inside a shell-like REPL rather than just a fancy shell.

It's interesting until you run up against speed limitations both left and right. I still use it for some work and enjoy it, but it is by far the slowest technology I've used.

Believe it or not you have to disable the progress bar to speed some things up. Downloads alone are at least 10x faster if you disable progress bar.

Re: Four features that justify a new Unix shell

#76

Post by tomjakubowski »

aeyes wrote: post #59
ritchiea wrote: post #7

Earlier quoted context omitted.

Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?

Working with large amounts of files or analyzing the content of large files. Not only will you be faster in glueing commands together with pipes but tools like find, grep, sed, awk, cut and so on will also perform much much better than interpreted languages. Also, I'd never prefer using the stdlib of Python/Ruby/etc for system commands like cp/chmod etc. It takes way more boilerplate code than a oneliner.

You can without too much work build a Python DSL which makes stuff like executing those oneliners as easy as x("cp", "foo", "bar"). And then you never have to worry about quoting command arguments again.

Re: Four features that justify a new Unix shell

#77

Post by oblio »

quotemstr wrote: post #50
oblio wrote: post #48

Earlier quoted context omitted.

Fish is incompatible with bash...

Every shell that changes how quoting works is incompatible with bash

There are different degrees of breakage and you should read his blog.

One of the modes is compatible with 99% of the bash scripts used out in the wild.

Re: Four features that justify a new Unix shell

#78

Post by johnisgood »

FreshFries wrote: post #71
R0b0t1 wrote: post #66

Earlier quoted context omitted.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was lit…

There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live. I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers. /rant.

I hate everything there is to hate about CPAN. I also hate how Perl libraries are handled. I have to have like 5 lines of code related to it in ~/.bashrc or ~/.bash_profile. Bleh. Perl libraries are always a problem when I want my program to run on other machines. No thank you.

Re: Four features that justify a new Unix shell

#79

Post by threeqhan »

FreshFries wrote: post #71
R0b0t1 wrote: post #66

Earlier quoted context omitted.

There is a better option and its name is Perl. Perl mixes the ins of shell scripts like easy argument and output passing with complex and easy to use control structures. You could use Python, but having been forced to use Perl extensively Perl is the superior choice for a complex shellscript-like workload. There's less boilerplate in Perl. There's a couple Python projects that come close like Fabric, but Perl was lit…

There is nothing in the (IT) world I fear more then... Perl projects. The shear madness it will leash upon you when the dependencies fail is maddening. Never will I voluntarily touch anything written in Perl ever again in my live. I've seen the power of Perl, the beauty and elegance of it, but everything was ruined by the absolute shit show when it comes to its packet managers. /rant.

Sheer as in "unmitigated" and shear as in sheep

But I agree with this, except for python

Re: Four features that justify a new Unix shell

#80

Post by ritchiea »

aeyes wrote: post #59
ritchiea wrote: post #7

Earlier quoted context omitted.

Are there ever good reasons to choose a shell script over a Python/Ruby/etc script?

Working with large amounts of files or analyzing the content of large files. Not only will you be faster in glueing commands together with pipes but tools like find, grep, sed, awk, cut and so on will also perform much much better than interpreted languages. Also, I'd never prefer using the stdlib of Python/Ruby/etc for system commands like cp/chmod etc. It takes way more boilerplate code than a oneliner.

Certainly not impossible but I don’t often have to deal with large amounts of files in circumstances where the performance hit matters to anyone. And while I know sed, awk, etc are powerful, I don’t know them & I’d have to learn how to use them, whereas I do know Ruby & Python.

At the very best this is an edge case where one would have reason to choose shell scripts over scripting languages.

Post reply on HN