local unfunction

local unfunction

[Ray Andrews]

Is it possible to unfunction something just within another function?  
I've tried:

unset -fm ....

... but the functions remain dead after the calling function returns.  I 
can of course just resource them, but I'll bet the unset can be made local.

Re: local unfunction

[Bart Schaefer]

On Fri, Mar 30, 2018 at 9:11 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Is it possible to unfunction something just within another function?  I've
> tried:
>
> unset -fm ....
>
> ... but the functions remain dead after the calling function returns.  I can
> of course just resource them, but I'll bet the unset can be made local.

You can get that effect like this:

% zmodload zsh/parameter
% inner() { print $0 }
% outer() { local +h functions; unfunction inner; which inner }
% which inner
inner () {
    print $0
}
% outer
inner not found
% which inner
inner () {
    print $0
}

HOWEVER, this not "safe" with autoloaded functions that have not been
loaded yet:

% zmodload zsh/parameter
% outer() { local +h functions; unfunction inner; which inner }
% autoload -U -k inner
% which inner
inner () {
    # undefined
    builtin autoload -XUk
}
% outer
inner not found
% which inner
inner () {
    builtin autoload -XU
}

Note that the "# undefined" tag and the -k flag have been lost;
"inner" is no longer a true autoloaded function.  (I think it is
probably a bug that $functions[inner] does not have the -k flag.)

Re: local unfunction

[Ray Andrews]

On 30/03/18 11:47 AM, Bart Schaefer wrote:
> On Fri, Mar 30, 2018 at 9:11 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Is it possible to unfunction something just within another function?

>> You can get that effect like this:
>>
>> % zmodload zsh/parameter
... that's way beyond my competence Bart but I will study it. However 
I'm playing with Mikael's use of parenthesis -- I'd swear this is the 
first time I've seen any such thing -- and it seems too good to be true, 
so far it just works.  Are there any lurking gotchas?  Disadvantages? It 
doesn't seem any slower.

BTW, just to keep flogging a dead horse:

function test1 ()
{
echo  "\none"
whence -a "zsh"
echo  "\ntwo"
whence -ma "zsh*"
echo  "\nthree"
whence -m "zsh*"
}

one
/usr/local/bin/zsh
/usr/bin/zsh
/bin/zsh

two
/usr/local/bin/zsh    # Missing below
/usr/bin/zsh          # Missing below
/bin/zsh              # Missing below
/aWorking/Bin/zsh5.3  # OK, added as a wildcard match. Executable.

three
/aWorking/Zsh/System/zsh    # Missing above NOT executable, plain text.
/aWorking/Bin/zsh5.3        # Executable, why this and not the others?
/aWorking/Bin/zsh5.3:       # Missing above NOT executable, plain text.

... '-m' by itself seems very strange, but even if we presume that it is 
to show non-executables, it does show one of them while missing all the 
others.  It also missed a non executable in the current directory even 
tho 'dot' is on the path (if we presume it looks for non-executables but 
that's hardly what whence seems to be for).  '-a' and '-ma' seem to 
behave as one might expect.  (I have a bunch of practice targets all 
over the place).  '-m' seems to find executables only if globbing was 
needed to find them, plain vanilla 'zsh' executables are not found.  Is 
this really what is wanted?

Re: local unfunction

[Bart Schaefer]

On Fri, Mar 30, 2018 at 5:30 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> playing with Mikael's use of parenthesis -- I'd swear this is the first time
> I've seen any such thing -- and it seems too good to be true, so far it just
> works.  Are there any lurking gotchas?

It's just creating a subshell, like any other time you'd put one or
more commands in parentheses.

The "lurking gotcha" is that because it is a subshell it can't affect
the parent shell in any way.  That's what Mikael means by "cancel all
other side effects" which he demonstrates with a=5.

> Disadvantages? It doesn't seem any slower.

It does fork an additional process.

> BTW, just to keep flogging a dead horse:
>
> function test1 ()
> {
> echo  "\none"
> whence -a "zsh"
> echo  "\ntwo"
> whence -ma "zsh*"
> echo  "\nthree"
> whence -m "zsh*"
> }

Try adding -w to get whence to tell you which hash table it's reading from.

Re: local unfunction

[Ray Andrews]

On 30/03/18 10:23 PM, Bart Schaefer wrote:
> It's just creating a subshell, like any other time you'd put one or
> more commands in parentheses.
Well nuts, I had no idea.  Checking tho I see it is in Peter's book, but 
at the time the notion of a subshell seemed strange and pointless.  Not so.
>
> The "lurking gotcha" is that because it is a subshell it can't affect
> the parent shell in any way.  That's what Mikael means by "cancel all
> other side effects" which he demonstrates with a=5.
Right, but in this case that's exactly to the point.  Not a gotcha, but 
a feature.
>
> It does fork an additional process.
Yeah, I've always presumed there must be some huge overhead in that, but 
it doesn't seem so. I just ran a stress test and the parenthesis add 7% 
in run time, ca. 20 milliseconds.  More subshells in my future.  Sounds 
like it's not a complete restart of the shell from disk  but a sorta 
fast cloning from memory or something like that, so not too much labor.

> Try adding -w to get whence to tell you which hash table it's reading 
> from. 

  $ which -mwa zsh
zsh: command
zsh: command
zsh: command

... I had looked at that but the output doesn't seem to say anything useful.

Re: local unfunction

[Mikael Magnusson]

On Fri, Mar 30, 2018 at 6:11 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Is it possible to unfunction something just within another function?  I've
> tried:
>
> unset -fm ....
>
> ... but the functions remain dead after the calling function returns.  I can
> of course just resource them, but I'll bet the unset can be made local.

If it's okay to also cancel all other side effects, you can use a subshell,
function() hey {
  normal stuff here
  (
     unfunction foo
     foo
     a=5 # this will also disappear after the )
  )
}

-- 
Mikael Magnusson