
Modernish: a shell moderniser library - sundarurfriend
https://github.com/modernish/modernish#modernish-a-shell-moderniser-library
======
oweiler
While I applaud the effort and extensive documentation I'd never use something
like this in production.

For example have a look at the definition of `sfor`

    
    
        sfor 'i=1' '[ "$i" -le 10 ]' 'i=$((i+1))'; do
            print "$i"
        done
    

Doesn't look too bad at first, until you realize `sfor` is an alias which is
defined as

    
    
        alias sfor='_Msh_sfor_init=y && while _Msh_doSfor'
    

So it's an alias which expands to two commands.

No have a look at the definition of `_Msh_doSfor`

    
    
        _Msh_doSfor() {
            case ${#},${_Msh_sfor_init+y} in
            ( 3, )	eval " $3" || die 'sfor: loop command failed' || return ;;
            ( 3,y )	eval " $1" || die 'sfor: init command failed' || return
                    unset -v _Msh_sfor_init ;;
            ( * )	die "sfor: 3 arguments expected, got $#" || return ;;
            esac
            eval " $2" || case $? in
            ( 1 )	return 1 ;;
            ( * )	die "sfor: test command failed" ;;
            esac
        }
    

No thanks, I'd rather use Python.

~~~
yorwba
I think the point of this library is that all those gory details necessary for
sane error handling are encapsulated, so you can build on that work if you
absolutely need to write shell scripts. Otherwise, yeah, I hope that Oil will
be the promised better shell and make bash & co. obsolete.

------
jph
This is _amazing_ for shells. Thank you for writing it.

Your reasoning and explanations are first rate, and the documentation is
superb.

Your emphasis on POSIX is a great approach for working on a very wide variety
of shells, including older ones and regulated ones. I deal with these
regularly at enterprise clients, and I'm excited to try Modernish with these.
Kudos!

~~~
sundarurfriend
Hey, it's good to know you found it so useful. Just to be clear though, I just
found and posted this here; Martijn Dekker [1] seems to be the main
contributor and presumably the creator of the library.

His email ID, according to a personal web page of his [2], is martijn
at_the_rate_of inlv dot demon dot nl , in case you wish to send the kudos
along his way.

[1] [https://github.com/McDutchie](https://github.com/McDutchie)

[2] [http://www.inlv.demon.nl/martijn/index-
old.html](http://www.inlv.demon.nl/martijn/index-old.html)

------
tibbetts
Isn’t this going to make shell scripts that were already fragile on anything
but bash not only fragile but also harder to debug? Combining the engineering
ideas of JavaScript and autoconf with the checkered history of shell scripts
seems like a case of -1 + -1 = -5.

~~~
xiaq
It is more like polyfills that serve to defragment different shells and
provide more modern constructs.

------
chatmasta
This looks really, really good. I’ve been looking for something like this for
a while, even considered building it myself.

Javascript and Shell programs are actually pretty similar IMO. Both are
loosely functional languages that can run in many different environments, with
different feature sets in each. Both run from a single entry point. A lot of
JS tooling could be applied to Shell scripting.

This library takes the right approach, by augmenting existing functionality
with syntactical sugar for safer programming. The wrong approach is the many
libraries attempting to make a “new” shell language, or a “superset” of shell.
The beauty of shell programming is its portability, but that’s lost once you
have even a single feature relying on non-POSIX functionality.

I like the Modernish approach because it’s _just a library_ , but writing it
can feel like writing a cleaner version of shell. The docs say Modernish was
inspired by jquery, but I would argue it’s more akin to underscore or lodash
in this sense.

Following the trend of shell/JS similarities, what I would like to see is a
compiler and packaging system similar to webpack and npm. I’m not talking
about a package manager that downloads libraries and binaries into some
directory in $PATH, but rather a bundler that compiles all libraries imported
from an entrypoint into a single executable shell script.

~~~
oweiler
Shell is so much not functional. Most shells don't even have proper functions.
And while pipes resemble function composition to some extent, you have side-
effects and mutations everywhere.

~~~
chubot
If you think of stdin and stdout as your function inputs and outputs, then
shell becomes very functional:

 _Pipelines Support Vectorized, Point-Free, and Imperative Style_

[http://www.oilshell.org/blog/2017/01/15.html](http://www.oilshell.org/blog/2017/01/15.html)

In a sense, a shell can only return an exit code. But it's better to think of
that as an error handling mechanism rather than the return value, much like in
C. In C, it's idiomatic for functions to return values with "out params" (i.e.
a dynamically allocated a string).

Just like you can write C code that composes, you can also write shell code
that composes. And in many ways it composes _better_ than code in other
languages.

------
chrisweekly
Looks amazing.

Note "use safe" in the README is missing some words:

> "Does IFS=''; set -f -u -C, that is: field splitting and globbing are
> disabled, variables must be defined before use, and"

~~~
McDutchie
Thanks for the report. Fixed.

------
ape4
If some modernish functions become popular they might be adopted by bash. So
it can be like a testing ground.

