Along the same lines: http://geophile.com/osh

Except that instead of bash, it's based on Python. So instead of everything being a string, you have the Python type system. E.g. 50 factorial:

    z@minizack:~$ osh gen 50 1 ^ red '*' $
    30414093201713378043612608166064768844377641568960512000000000000

This red(uce)s using multiplication the stream of integers 1..50.

Find the pids of python processes:

    z@minizack:~$ osh ps ^ select 'p: "python" in p.commandline' ^ f 'p: p.pid' $
    (2094,)
    (2394,)

This pipes process objects from one command to the next. First select the processes whose commandline contains "python", then run a function that maps the process to its pid.

Which is along the same lines as

https://github.com/pixelb/scripts/blob/master/scripts/funcpy

http://code.google.com/p/pyp/

The nightmare of writing any kind of serious program in the shell was the inspiration for PBS https://github.com/amoffat/pbs

Wow... Just wow... I always thought there should be something more intuitive than the subprocess module.

This actually makes it practical to use python where I would usually use shell scripts.

That API is actually quite well designed, thanks. I don't really use Python anymore, but if I did I'd really consider using it. Although "bake" should really be "curry".

You shouldn't write anything serious in shell or python, use serious language for serious jobs, please.

(But if you do, use bash-modules, please).

Care to explain why?

The shell gives this kind of behaviour already through pipes and commands like awk, sed, and dc. More natural translations of the calculations given might be

    $ seq 100 | awk '{s += $0} END {print s}'
    5050
    $ seq 20 | awk -v s=1 '{s *= $0} END {print s}'
    2432902008176640000
    $ seq 5 | awk -v s=1 '{s *= $0} END {print s}'
    120
    $ seq 3 |
    > awk -v s=1 '{s *= $0} END {print s}' |
    > xargs seq |
    > awk '{s += $0} END {print s}' |
    > md5sum
    fe9d26c3e620eeb69bd166c8be89fb8f  -
    $ seq 400 500 | awk '{s += $0} END {print s}'
    45450
    $

Better yet, SCSH

http://www.scsh.net/

>>Simplest type system in the world: everything is a string!

This is an extremely important, yet most unrealized statement in the history of computers. Data is actually Text, and it strange so many people are unaware of Data/Text/String processing utilities and tools.

In my opinion everyone must learn how to use Unix text processing utilities along with Perl.

Often I see so many programmers, write small buggy sub set implementations of a few features of tools like awk, sed all the time. Especially if you are coming from a ecosystem like Java, its a habit to keep writing code for everything. Re inventing and writing code for things like what you can do in a line of sed or awk.

I've seen these problems more in XML heavy, and in general projects that don't involve a database. If only you would know how to represent your data in a more field based format like tsv, csv or even other record based files which can handled with some separator. You can save yourself writing several hundreds to thousand lines of code, by just using unix text processing utilities.

Of course if you know Perl you can move mountains like you move feathers.

Lastly, I would say those who don't understand Unix(and its ecosystem) are condemned to re implement it badly.

I agree that programmers should learn the 'Unix philosophy', but lumping Perl in there doesn't make much sense. Perl is just a scripting language, like Python or Ruby, and one of which I'm not particularly fond. It does not espouse 'one tool, one task' — "those days are dead and gone and the eulogy was delivered by Perl." Definitely learn shell, awk, sed, and co. But avoiding Perl won't do any harm.

>>Perl is just a scripting language

And its amazingly great at that. I don't know any other language which as powerful as Perl for back end work. There is whole world inside that 'Just' which many other languages suck at.

>>"those days are dead and gone and the eulogy was delivered by Perl." Definitely learn shell, awk, sed, and co. But avoiding Perl won't do any harm.

The only harm you will incur is never understand what Perl offers and try to recreate the same magic in some other language. Often writing highly verbose pieces of code to do what Perl offers in a more neat, concise and better way.