Re: How to change environment from a module

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 29,  7:32pm, Mark Hessling wrote:
}
} [Bart wrote:]
} > In general you shouldn't call bin_ functions directly.  They
} > should almost always be called only via the command execution
} > code.
} 
} Why should these functions not be called directly ?

Because they often depend on the generic command setup that is performed
in the execution code in exec.c.

} > It's very likely that your module should call zgetdir(&ds) before
} > running the Rexx program and call restoredir(&ds) after it.
} 
} But this is the only reason for running a Rexx interpreter within the
} current process of the shell; to change the environment permanently.

I can think of other reasons, such as avoiding the overhead of repeated
forks and of reloading the interpreter.

} Based on this premise, then calling routines like zchdir() doesn't
} go the whole way. ie if you have a chpwd() function in .zshrc, then
} zchdir() doesn't call it.

That's true -- zchdir() is a function meant to be called by the zsh
internals at a lower level than the command interpreter.

} So again, how should one call the bin_*() functions directly from a
} module as though a "cd" command or "export" command were executed
} directly by the user ?

This is akin to asking how to attach a clutch pedal to an autmobile with
an automatic transmission.  Just because there's a clutch plate in there
somewhere doesn't mean there's an easy way to bolt new a lever to it.
In fact, you're trying to connect an entire second engine to the drive
chain, and wondering why the chassis wasn't designed for that.

The best suggestion I can give you is:

    sprintf(command, "\\builtin cd %s", bslashquote(dirname, NULL, 0));
    execstring(command, 1, 0);

Where it's up to you to be sure that the command buffer is large enough.