> Thank you for investigating this in such great detail. > > > A Tcl::pTk user opened > a ticket observing this issue in the > test suite: > https://rt.cpan.org/Ticket/Display.html?id=132278
Can you open the ticket on Tcl.pm, given that we see that it is more relevant here? > > I had briefly looked online > for previous reports of similar issues > for Tcl and Perl, and there were plenty > of bug reports and improvements > submitted, often from 20+ years ago. I don't > think I came across > this exact issue. But in some cases this kind of issue was > deemed > expected behavior, so I wouldn't be surprised if raising this > specific > issue with either Perl or Tcl today that they still consider > it to be neither > new nor unexpected. For example, a program embedding > Tcl is supposed to do > things like use/redefine Tcl_PutEnv() > (see > https://www.tcl-lang.org/man/tcl8.6/TclLib/Environment.htm). I've browsed tcl source code and IMO I've found a bug here (which is not affecting logic and not causing coredumps, but makes some minor inefficiency) This isn't of any importancy though > But this would > appear to assume the program writer is/should be > in control of compiling and > packaging everything in their program. > It is not possible to do this when > intending for Tcl.pm reuse > existing Tcl or Perl installations, such as from > package managers. IMO linker will use your function, if you redefine it in your code and will pass it sooner to linker. So you can "neutralize" freeing environment variables in libtcl IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's environment call - what is it? According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-functions - this is my_setenv? > So maybe Tcl.pm will have to document this as a known issue. > > Or, is there a workaround possible in the meantime? I will work on the fix, when time permits
