How to change environment from a module

How to change environment from a module

[Mark Hessling]

I'm writing a fairly simple module that will allow the execution of a Rexx
program within the same process as zsh.
Execution of the Rexx program works fine at the moment, but the main reason
for wanting to run a Rexx program this way is to allow the Rexx program to
make changes to the current environment; ie environment variables and
current working directory.
So, from within the module I have, I need to be able to do the following:
1) Get the current value of an environment variable
2) Set the value of an enviornment variable
3) Get the value of the current working directory
4) Set the value of the current working directory

I thought I might be able to use bin_cd() and bin_typeset() to set the
appropriate values, but at least for bin_typeset() I don't know how to set
up the "options" argument properly. When I call it, I get "invalid
option(s)" error displayed.

So my questions are:
1) Should modules be able to call builtins as described above ?
2) How does one get the values of an environment variable and current
working directory from within a module ? (There aren't really any builtins)

TIA

Cheers, Mark.

Re: How to change environment from a module

[Bart Schaefer]

On Dec 22,  3:24pm, Mark Hessling wrote:
}
} So, from within the module I have, I need to be able to do the following:
} 1) Get the current value of an environment variable
} 2) Set the value of an enviornment variable
} 3) Get the value of the current working directory
} 4) Set the value of the current working directory
} 
} I thought I might be able to use bin_cd() and bin_typeset()

In general you shouldn't call bin_ functions directly.  They should almost
always be called only via the command execution code.

} 2) How does one get the values of an environment variable and current
} working directory from within a module ?

Most likely you want these functions:

	createparam(variablename, PM_EXPORTED);
	getsparam(variablename);
	setsparam(variablename, valuestring);

	struct dirsave ds;
	dir = zgetdir(&ds);
	restoredir(&ds);

It's very likely that your module should call zgetdir(&ds) before running
the Rexx program and call restoredir(&ds) after it.  That is, the Rexx
program should not permanently change the shell's current directory.
Within the Rexx program, the usual chdir() system call can be used (but
the values of the PWD and OLDPWD variables cannot be relied upon).  In
this sense the Rexx program would behave as if it is an external command.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: How to change environment from a module

[Mark Hessling]

> On Dec 22,  3:24pm, Mark Hessling wrote:
> }
> } So, from within the module I have, I need to be able to do the
> following: } 1) Get the current value of an environment variable
> } 2) Set the value of an enviornment variable
> } 3) Get the value of the current working directory
> } 4) Set the value of the current working directory
> } 
> } I thought I might be able to use bin_cd() and bin_typeset()
> 
> 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 ? See below for more
explanation.

> 
> } 2) How does one get the values of an environment variable and
> current } working directory from within a module ?
> 
> Most likely you want these functions:
> 
>     createparam(variablename, PM_EXPORTED);
>     getsparam(variablename);
>     setsparam(variablename, valuestring);
> 
>     struct dirsave ds;
>     dir = zgetdir(&ds);
>     restoredir(&ds);
> 
> It's very likely that your module should call zgetdir(&ds) before
> running the Rexx program and call restoredir(&ds) after it.  That
> is, the Rexx program should not permanently change the shell's
> current directory. Within the Rexx program, the usual chdir()
> system call can be used (but the values of the PWD and OLDPWD
> variables cannot be relied upon).  In this sense the Rexx program
> would behave as if it is an external command.

But this is the only reason for running a Rexx interpreter within the
current process of the shell; to change the environment permanently.

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. It seems that only a call to bin_cd() will result in a
call to chpwd().

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 ?

Cheers, Mark.

> 
> -- 
> Bart Schaefer                                 Brass Lantern
> Enterprises http://www.well.com/user/barts             
> http://www.brasslantern.com
> 
> Zsh: http://www.zsh.org | PHPerl Project:
> http://phperl.sourceforge.net

Re: How to change environment from a module

[Bart Schaefer]

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.

Re: How to change environment from a module

[Mark Hessling]

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

Fair enough.

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

Yes, but they are not the primary practical reasons from a user's
perspective; particularly one from an OS/2 background where the Rexx
interpreter there is an integral part of the shell. Its this behaviour I'm
trying to duplicate with zsh.

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

Crude but very effective :-) Works like a charm! Also did the same with
"\\builtin export %s=%s", and it also works exactly how I wanted.
Many thanks Bart for your suggestions, the module works great.

One last question; naming standards for modules. Are third-party modules
allowed to start with "z" ? eg. I've called mine "zregina", so that the
"regina" executable will still be available as an external program.

Cheers, Mark.

Re: How to change environment from a module

[Zefram]

Mark Hessling wrote:
>One last question; naming standards for modules. Are third-party modules
>allowed to start with "z" ? eg. I've called mine "zregina", so that the
>"regina" executable will still be available as an external program.

You seem to be confusing two namespaces here: modules and builtin
commands.  Each module provides zero or more builtin commands; there is
no necessary relationship between the name of a builtin and the name of
the module that provides it.

For the builtin command that you're providing, I suggest using the same
name as the external program if and only if you are providing the same
behaviour (as the builtins such as "rm" in the "zsh/files" module do).
In this case the external program is still available by using the
"command" builtin, but it shouldn't be necessary to use that.  If you
are providing different behaviour, such as having the command modify
zsh's environment, then use a different name; a "z" prefix to indicate
such a variation of behaviour seems entirely appropriate, and I see no
reason for us to disapprove of third-party use of such names.

Modules have a hierarchical namespace, with the first component of the
name identifying the entity publishing the module.  Modules from the
Zsh Development Group have names starting "zsh/", such as "zsh/zle"
(the zsh line editor) and "zsh/files" (file manipulation builtins).
You should name your modules in a similar fashion; e.g., you could use
module names starting "hessling/" if you're publishing them yourself.

In the common case of a module providing only a single builtin, usually
the builtin's name is also a good way to identify the functionality of
the module (e.g., "zsh/sched" providing the "sched" command).  So you
might want to use the module name "hessling/zregina", if my guesses
about the appropriate command name and module publisher were correct.

-zefram