Forum OpenACS Development: Re: NaviServer 4.99: Issues with "rename"?

i have spent a lot of time about handling exec issues of tcl in aolserver and naviserver, which usually only happen under heavy usage, when the server have log uptimes, etc. I am just pointing out consequences of design decisions, which the person rewriting "exec" for application specific needs might not have been aware off.

The "right approach" is the one which reduces on the longer range the maintenance cost and reliability complaints....

Hi Gustaf,

I'm back at the issues of "renaming exec" on Windows. I believe I've got a simple issue with TCL namespaces. This has nothing to do with nsproxy!

I'm frankly not motivated enough to re-write all this crud, I just want it to work like it was before.

And that's very simple: Commands are plain Linux commands ("/bin/pwd"). ]po[ relies on a complete CygWin installation, so that all commands are "there". Now we just need to add a "C:/project-open" in front of any Linux command in order for exec to work.

I've got the following code (simplified):

rename ::exec ::exec_orig
proc exec {args} { return [eval "::exec_orig C:/project-open$args"] }
ns_log Notice "exec: pwd=[exec "/bin/pwd"]"

This code works during NaviServer startup on Windows. However, it doesn't work when executing "exec /bin/pwd" from an OpenACS shell with the error messge "invalid command name "::exec_orig"". exec_orig somehow disappeared from [info commands].

Any idea?

Thanks!
Frank

Dear Gustaf and Frank,
I will try to explain the current situation for the Windows port (at least my installer).

1. the renaming was implemented in an old file "acs-tcl\tcl\windows-procs.tcl".

2. At least in my distribution that file is disabled, by calling it "windows-procs.tcl.org".

3. So my distribution uses the standard "exec" (when the nsproxy module is not loaded, that is
ns_section ns/server/${server}/modules
ns_param nssock ${bindir}/nssock.dll
# ns_param nsproxy ${bindir}/nsproxy.dll
)

4. with this configuration, running for instance the command:

exec psql -U postgres -l

works and produces the following output:

List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------------+----------+----------+-----------------------------+-----------------------------+-----------------------
kedrios | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
machines | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
machines_new | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
postgres | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
projop | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
sonar | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 |
template0 | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | English_United Kingdom.1252 | English_United Kingdom.1252 | =c/postgres +
| | | | | postgres=CTc/postgres
(8 rows)

5. the nsproxy module only recently (yesterday) got compilable under Windows and it is available in my distribution from today. With that module loaded, that is:
ns_section ns/server/${server}/modules
ns_param nssock ${bindir}/nssock.dll
ns_param nsproxy ${bindir}/nsproxy.dll
the same psql command given in the ds shell produces the following output:
ERROR:
exec failed: no such file or directory
while executing
"ns_proxy get ExecPool"
(procedure "::nsf::procs::proxy::exec" line 3)
invoked from within
"proxy::exec -call $args"

In fact also nsproxy renames the original exec.

Hope it helps,
Maurizio

Dear Gustaf,
I believe we are talking in circles.
You wrote:
"Under windows, there should be a nsproxy.exe and a nsproxy.dll. Do you have these?".
The only important outputs of the Windows build process are nsd.exe and all modules *.dll files.
Executables like nssock.exe, or nsproxi.exe, etc.. are the intermediate build products created/used by the legacy nmake "makefiles".
And of course I had the nsproxy.dll in place. When you specify in the config file that you need to load a module (a *.dll) if it doesn't find it, it complains.
You also wrote
"The "exec" definition in OpenACS does not rename "exec", but it overloads it. That makes it problematic, if one tries to rename it in addition".
What I can see in the files is that both windows-procs.tcl (line 22) and proxy-procs.tcl (line 40) call a rename.
And what I can say is the following:
1. in my configuration/installer I do not load the windows-procs.tcl file, so that renaming does not take place.
2. when I use the system without loading nsproxy.dll the exec command works and looks for binaries in the specified PATH.
3. when I use the system with nsproxy.dll loaded the exec command does not work (and a renaming takes place).
4. Frank does not need nsproxy, I mean in the context of this discussion. He only needs a "new" exec to have control on where the system looks for binaries. So he can probably take the "new" exec in the windows-procs.tcl and modify it as he requires/pleases.

Hope it helps,
Maurizio

Hi!

Short update: We are on the way to replace all exec ocurrences in ]po[ with "im_exec", which will include the Windows specific logic. So there is no "rename" anymore.

So I have moved the content from acs-tcl/tcl/windows-procs.tcl into this im_exec routine.

im_exec in turn calls exec, after some transformations of the arguments into a format that works with CygWin.

Cheers,
Frank