Higher order functions in zsh (article link)

Higher order functions in zsh (article link)

[rahul]

[-- Attachment #1: Type: text/plain, Size: 153 bytes --]

THis has been posted on reddit programming, thought I'd share with you.

http://yannesposito.com/Scratch/en/blog/Higher-order-function-in-zsh/index.html

Re: Higher order functions in zsh (article link)

[Christopher Browne]

On Thu, Mar 7, 2013 at 12:25 AM, rahul <rahul2012@gmail.com> wrote:
> THis has been posted on reddit programming, thought I'd share with you.
>
> http://yannesposito.com/Scratch/en/blog/Higher-order-function-in-zsh/index.html

Seems promising.  I added in notes about a case on which it breaks, at this
point.

> touch f1 f2\ with\ space f3\'with\'quotes
> map echo *
f1
f2 with space
f3withquote

The "obvious" change to map is thus:

cbbrowne@cbbrowne /tmp/maptest> function map {
    local func_name=$1
    shift
    for elem in $@; print -- $(eval $func_name "${elem}")
}

But somewhat curiously that doesn't help :-(.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: Higher order functions in zsh (article link)

[Phil Pennock]

On 2013-03-07 at 11:59 -0500, Christopher Browne wrote:
> cbbrowne@cbbrowne /tmp/maptest> function map {
>     local func_name=$1
>     shift
>     for elem in $@; print -- $(eval $func_name "${elem}")
> }
> 
> But somewhat curiously that doesn't help :-(.

Why does this code have an eval in there?  It's:
 (1) breaking the f3 example
 (2) introducing a security flaw

Hint:  touch 'f4 `mkdir snert`'

This works fine:
----------------------------8< cut here >8------------------------------
function map {
	local func_name=$1
	shift
	for elem in "$@"; print -- $($func_name "${elem}") 
}
----------------------------8< cut here >8------------------------------

With the eval in there, with { map echo * } f3 loses the quotes and f4
just shows "f4" and creates a new sub-directory, snert.

Lose the eval and things work, no new security hole.

Oh, and you need to quote the $@ to "$@" if you want to preserve empty
elements -- whether you do or not depends on what you're mapping across,
but I tend to think "present but empty" is distinct from "not present".

-Phil

Re: Higher order functions in zsh (article link)

[Oliver Kiddle]

Phil Pennock wrote:
> Why does this code have an eval in there?  It's:

I suspect that the eval was there to allow the command to include
arguments: e.g. map 'print -l' *
Using $=func_name will add word-splitting to get that back without
reintroducing the security flaw.

> Oh, and you need to quote the $@ to "$@" if you want to preserve empty
> elements -- whether you do or not depends on what you're mapping across,
> but I tend to think "present but empty" is distinct from "not present".

Actually "$@" is the default for a for loop so you don't need it. And I
can't see that the use of print and command-substitution gets you
anything unless I'm missing something. So:

function map {
    local func_name=$1 elem
    shift
    for elem; $=func_name "${elem}"        
} 

This is unrelated but it seems the warncreateglobal option does't warn
about variables created using a for loop. Does anyone know if that is
intentional or a bug?

Oliver

Re: Higher order functions in zsh (article link)

[Stephen Blott]

On Thu, Mar 07, 2013 at 10:55:01AM +0530, rahul wrote:
>THis has been posted on reddit programming, thought I'd share with you.
>
>http://yannesposito.com/Scratch/en/blog/Higher-order-function-in-zsh/index.html
---end quoted text---

The examples look like those of a Java programmer translating their Java 
programming style to shell programming.  They can be better solved with 
zargs or, if you insist on a Posix shell, then pipes.  Pipes in Unix-like 
systems play exactly the role of map, filter and reduce in functional 
systems.

That's not to say that there's no merit to the idea.  I'd just like to see 
more compelling examples.

Steve