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.

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.

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!

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

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

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.

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

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.

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.

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

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.

Agreed. Hence why I said “loosely functional” (you could say the same about JS).

For both languages you can write code as functional or non functional as you want. Input/output redirection (pipes), IMO, could qualify as functional programming just as JS promise chaining could.

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"

Thanks for the report. Fixed.

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