6 ms·

Functional programming in sh

59 points by michael_fine 14y ago

geophile 14y ago
Along the same lines: http://geophile.com/osh 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.
- pixelbeat 14y ago
  Which is along the same lines as https://github.com/pixelb/scripts/blob/master/scripts/funcpy https://github.com/pixelb/scripts/blob/master/scripts/funcpy http://code.google.com/p/pyp/ http://code.google.com/p/pyp/
deleted 14y ago
[deleted]
daenz 14y ago
The nightmare of writing any kind of serious program in the shell was the inspiration for PBS https://github.com/amoffat/pbs https://github.com/amoffat/pbs
- vlisivka 14y ago
  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).
  - surement 14y ago
    Care to explain why?
- entropy_ 14y ago
  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.
- lubutu 14y ago
  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".
mahmud 14y ago
Better yet, SCSH http://www.scsh.net/ http://www.scsh.net/
deleted 14y ago
[deleted]
- mikeplus48 14y ago
  I'm the author of this post, it was a joke. I said "For those who have no idea what they're doing 90% of the time when they are in bash" very sarcastically, but obviously this wasn't conveyed very well, sorry. edit: I know the defense "it was a joke" is very overplayed, but really, somewhere in between the graphs with rainbows and explosions, this post was intended to be humourous. :)
  - a3d6g2f7 14y ago
    Sorry dude. I missed the sarcasm, obviously. I just used your statement as opportunity to rant about a recurring issue I see. I probably shouldn't have. It's certainly not directed at you. Maybe you were joking but sadly I'm afraid the statement I quoted is actually true for a lot of people. I'll delete my comment if I still can.
ralph 14y ago
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 $
kamaal 14y ago
>>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.
- lubutu 14y ago
  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.
  - kamaal 14y ago
    >>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.

59 points by michael_fine 14y ago

Along the same lines: http://geophile.com/osh 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.

pixelbeat 14y ago
Which is along the same lines as https://github.com/pixelb/scripts/blob/master/scripts/funcpy https://github.com/pixelb/scripts/blob/master/scripts/funcpy http://code.google.com/p/pyp/ http://code.google.com/p/pyp/

deleted 14y ago

[deleted]

daenz 14y ago

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

vlisivka 14y ago
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).
- surement 14y ago
  Care to explain why?
entropy_ 14y ago
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.
lubutu 14y ago
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".

mahmud 14y ago

Better yet, SCSH http://www.scsh.net/ http://www.scsh.net/

deleted 14y ago

[deleted]

mikeplus48 14y ago
I'm the author of this post, it was a joke. I said "For those who have no idea what they're doing 90% of the time when they are in bash" very sarcastically, but obviously this wasn't conveyed very well, sorry. edit: I know the defense "it was a joke" is very overplayed, but really, somewhere in between the graphs with rainbows and explosions, this post was intended to be humourous. :)
- a3d6g2f7 14y ago
  Sorry dude. I missed the sarcasm, obviously. I just used your statement as opportunity to rant about a recurring issue I see. I probably shouldn't have. It's certainly not directed at you. Maybe you were joking but sadly I'm afraid the statement I quoted is actually true for a lot of people. I'll delete my comment if I still can.

ralph 14y ago

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 $

kamaal 14y ago

>>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.

lubutu 14y ago
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.
- kamaal 14y ago
  >>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.