On Wed, 24 May 2017 20:00:51 -0400 "William L. Thomson Jr." <[email protected]> said:
> On Thu, 25 May 2017 08:32:17 +0900 > Carsten Haitzler (The Rasterman) <[email protected]> wrote: > > > On Wed, 24 May 2017 15:19:54 -0400 "William L. Thomson Jr." > > <[email protected]> said: > > > > before you init elm/efl: > > > > char buf[1024]; > > snprintf(buf, sizeof(buf), "DISPLAY=%s", pe->display); > > putenv(strdup(buf)); > > Did that, in a normal terminal where $DISPLAY exists > pe->display=(null) > > 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... 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. 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. > > why DISPLAY was not properly set for you before execution yet somehow > > has been provided to you via some other means... baffles me. > > It it passed to pinentry as an argument. > pinentry --display :0.0 > > Seems that value is set based on the argument and not env variable. > Since it was not set, when the variable existed. > > > seems a little unfriendly. whatever is executing you should set > > this. same for WAYLAND_DISPLAY > > That would have to come from the calling program. Which I think is > impractical, as that is everything that would use GPG, git, email > client, gpg cli, etc. Some things may vary but seems most are passing > via arg as above. actually it's totally practical. if the caller can add a --display=whatever it can to a putenv too. child processes AUTOMATICALLY inherit parent processes environments. if the call tree is: email app -> gpg -> pinentry 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. > > ... both of these should have already been set (well one or the > > other really, not both at once unless both display targets are > > available) before your process executes. that's how it works normally. > > They are but not passed along. To many things are passing it along to > go around patching everything for one or the other. I do not believe > there is another way via ENV at this time to obtain such. > > By the time pinentry is invoked it is in a different ENV without > $DISPLAY set. Even though it was available to the invoking program. > > Now there is a further issue, where pinentry when invoked from CLI only > looks for $DISPLAY, not $WAYLAND_DISPLAY. So its own > pinentry_have_display will fail under wayland causing it to fallback to > ncurses or tty UI. > > Seems a bug exists on this already under SUSE, small world... > https://bugzilla.suse.com/show_bug.cgi?id=997274 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. -- ------------- 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
