On Wed, 24 May 2017 23:11:35 -0400 "William L. Thomson Jr." <[email protected]> said:
> On Thu, 25 May 2017 10:16:43 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > > When invoked via background, not from ENV but arg, its > > > pe->display=:0.0 > > > > i didn't look where you get pe->display but your mail indicated that > > this is a string that contains the display info... > > You see what it contains, 0:0. That is not useful to say X or Wayland. it's totally useful for x11. it's 100% useful. it's how you define a local display in x11. wayland of course works differently in display string format. but it's totally useful. > > so use that for > > setting DISPLAY. DISPLAY *SHOULD* have already been set though as > > this is the normal way for an app to know how to display something. > > This is happening via pipes and maybe subshells that do not have access > to the same environment variables. it can be passed along and putenv()'d if that is not the case, but i find it unlikely it is the case. you would normally spawn gpg-agent (which is what i believe would do the spawning?) underneath your login session which then would have the env var. > > since whatever environment is executing you is not following these > > conventions that are more widely supported than a --display > > argument ... then you have to put this into the environment before > > efl inits. > > Code example? i gave you one. my very first reply to "[E-devel] Wrapper for ecore init". this exact thread. very very very first thing i said in that reply. > > then the env var should be inherited with zero effort on anyone's > > part. someone has to go to effort to remove the env var to make that > > not work. as long as "gpg" that spawns the pinentry is spawned from a > > "display session" where the environment has DISPLAY (and > > WAYLAND_DISPLAY etc.) set then it inherits this already UNLESS it > > explicitly decided to nuke that env var. > > The environment variables are not present. it's nuked them (likely). in fact it explicitly does. gpg-agent.c: main() /* Record some of the original environment strings. */ it saves DISPLAY. then later in main: if (!opt.keep_display) gnupg_unsetenv ("DISPLAY"); so it does nuke it. the reason is so it can provide a client profvided display to each pinentry - fair enough. but it can do that by forking then modifying DISPLAY env var in the fork then doing the exec() instead of assuming pinentry handles specific cmdline args. they chose to do it the argument way instead and thus create work. > > so it's checking DISPLAY then removing it then executing you and > > passing it as an arg instead. this smells to me of a whole bunch of > > extra work that never needed to be done... but either way you're > > stuck with it unless you patch gpg. you now have to set the env var > > from the cmdline args as i mentioned. > > Set it to what? Guess X or Wayland? Set it via code in pinentry-efl? pinentry does not even know about WAYLAND_DISPLAY. it doesn't unset it or store or touch it. at least not in 2.1.21 of gpg. it ignores it. so you'll inherit whatever gpg-agent inherits from its parent process. --display there is a specific x11 display string. that's what it has always been at any rate. see above. i already gave you the solution in my very first reply to this thread. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
