IRC, unknown channel, unknown date.
<cfhammar> BTW, is settrans -a supposed to clear all env variables? <cfhammar> or can I consider it a bug ;-) <cfhammar> scolobb: yeah, seems the problem is in libfshelp <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? <scolobb> (I can remember that it does something to the environment indeed) <cfhammar> scolobb: yes, I think it's the culprit <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. <cfhammar> scolobb: yeah, that's my guess also <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long <scolobb> cfhammar: Yeah, that's right <scolobb> I wonder what could the motivation for not passing the environment to a child process <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-)