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

81–90 of 185 posts

Re: Four features that justify a new Unix shell

#81

Post by zem »

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…

i find that ruby combines the best features of perl and python in that respect. makes shell-like scripts really convenient and easy while still providing the means to add structure.

Re: Four features that justify a new Unix shell

#82

Post by swirepe »

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.

I'm curious what scripting tasks you do with python? I've found bash to be more than enough for everything I'd like to script, except for maybe stuff with heavy json processing (still doable with `jq`)

Re: Four features that justify a new Unix shell

#83

Post by pmoriarty »

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.

I've actually started to transition my shell scripts to eLisp for better integration in to Emacs and eshell.

As a Lisp, eLisp is not the greatest, but I'd still much rather use it than Python.

I also don't want to sit and twiddle my thumbs while a Python script takes its sweet time in loading. Slow startup time is the kiss of death for most shell scripts.

Re: Four features that justify a new Unix shell

#84

Post by pmoriarty »

zem wrote: post #81
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…

i find that ruby combines the best features of perl and python in that respect. makes shell-like scripts really convenient and easy while still providing the means to add structure.

Both Ruby and Python are too slow for me, and neither is Lispy enough.

Re: Four features that justify a new Unix shell

#85

Post by TylerE »

pmoriarty wrote: post #84
zem wrote: post #81

Earlier quoted context omitted.

i find that ruby combines the best features of perl and python in that respect. makes shell-like scripts really convenient and easy while still providing the means to add structure.

Both Ruby and Python are too slow for me, and neither is Lispy enough.

nim!

It has full macros, even!

and it's super, super, fast

Re: Four features that justify a new Unix shell

#86

Post by quotemstr »

oblio wrote: post #77
quotemstr wrote: post #50

Earlier quoted context omitted.

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.

Yes, you're right. A closer examination of Oil yields something much more interesting than I imagined.

Re: Four features that justify a new Unix shell

#87

Post by pmoriarty »

TylerE wrote: post #85
pmoriarty wrote: post #84

Earlier quoted context omitted.

Both Ruby and Python are too slow for me, and neither is Lispy enough.

nim! It has full macros, even! and it's super, super, fast

Nim's not Lispy either, and macros alone are not enough. To make macro use feel natural because they're not much different than using the core language, the language needs to be homoiconic, which to my knowledge Nim is not.

In any case, macros are not what draw me to Lisp, but its unparalleled combination of ease of use, readability, and power... along with 70 years of development and tooling.

So I could just use a Lisp or Scheme, which I do. They can be plenty fast too (see Chicken, for instance, which -- like Nim -- compiles down to C).

Re: Four features that justify a new Unix shell

#88

Post by moritonal »

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.

Cross-platform Powershell (specifically with Azure though) has become oddly enjoyable.

Re: Four features that justify a new Unix shell

#89

Post by TylerE »

pmoriarty wrote: post #87
TylerE wrote: post #85

Earlier quoted context omitted.

nim! It has full macros, even! and it's super, super, fast

Nim's not Lispy either, and macros alone are not enough. To make macro use feel natural because they're not much different than using the core language, the language needs to be homoiconic, which to my knowledge Nim is not. In any case, macros are not what draw me to Lisp, but its unparalleled combination of ease of use, readability, and power... along with 70 years of development and tooling. So I could just use a L…

It's lispy in what it can do, not in having a rat's nest of parens, true.

I'd love a concrete example of a macro you could express in lisp and not in nim.

But it's macros absolutely operate on a syntax tree - refer to https://nim-lang.org/docs/tut3.html#introduction-the-syntax-...

Re: Four features that justify a new Unix shell

#90

Post by chubot »

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.

(author here) I do use Python. In fact I wrote something like 30K lines of Python for Oil.

The question isn't shell OR Python.

My shell scripts call Python scripts, many of white I wrote myself. That is working as intended.

They also call C programs, C++ programs and R programs. And put JavaScript programs in various places.

----

I guess this is a huge misconception about shell that I have to write a blog post about.

https://news.ycombinator.com/item?id=24083764

I'm often asked this about Oil [1]: Why do you want to write programs in shell?

That's not the idea of shell. The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages.

I need a language to glue them together. A language to express build automation and describe deployed systems. Most big systems consist of more than one language.

Shell is the best language for that, but it's also old and crufty, with poor implementations.

When you program in shell, gcc, git, pip, npm, markdown, rsync, diff, perf, strace, etc. are part of your "standard library".

-----

If you want some concrete examples, look in the Oil repo. There are dozens of shell scripts that invoke custom tools in Python, R, and C++.

https://github.com/oilshell/oil/tree/master/benchmarks

For example, to generate this report on how much we speed up Python by translating it to C++: https://www.oilshell.org/release/0.8.3/benchmarks.wwz/mycpp-...

The tables are manipulated by R code, and shell/Python/CommonMark generates the HTML.

-----

Another example is that the release page is essentially a huge shell script: https://www.oilshell.org/release/0.8.3/

This page and all the linked pages are generated by: https://github.com/oilshell/oil/blob/master/devtools/release...

------

If you don't understand why shell should call Python and C, I recommend reading The Art of Unix Programming

http://www.catb.org/~esr/writings/taoup/html/

https://www.amazon.com/UNIX-Programming-Addison-Wesley-Profe...

Post reply on HN