Skip to content
Snippets Groups Projects
Select Git revision
  • renovate/modernc.org-sqlite-1.x
  • renovate/github.com-strubbl-wallabago-v9-9.x
  • renovate/go-1.x
  • main default protected
  • debian
  • tristate
  • rtfd
  • 1.0.x
  • api2.2
  • titles
  • hugo
  • pelican
  • 1.6.0
  • 1.5.1
  • 1.5.0
  • 1.4.1
  • 1.4.0
  • 1.3.1
  • 1.3.0
  • 1.2.1
  • 1.2.0
  • 1.1.1
  • 1.0.2
  • 1.0.1
  • 1.1.0
  • 1.0.0
  • 0.9
  • 0.8
  • 0.7
  • 0.6
  • 0.5
  • 0.4
32 results

fbink.go

  • Antoine Beaupré's avatar
    d87b13ed
    fbink: fix path in wallabako's caller · d87b13ed
    Antoine Beaupré authored
    The implementation of on-screen display would frequently fail to
    run correctly, particularly when it would be started from udev. It
    seems that, from there, the PATH environment is just completely empty,
    which, naturally, makes it... hard for wallabako to find the fbink
    binary.
    
    It seems like my original implementation in 79745486 (implement basic
    fbink output (#49), 2023-06-09) already had this hack to try to add to
    PATH, but that didn't work: I suspect exec.Command doesn't look at the
    provided Env for the PATH environment. This is a bit counter-intuitive
    to me, but actually makes sense: Env is passed *to* the subprocess,
    but the PATH used is the one from the *calling* process.
    
    (I haven't actually confirmed this, but I can definitely confirm that
    fixing this in the script udev calls actually works. A golang-only fix
    would be to change wallabako's PATH directly, but that seems more
    intrusive and unnecessary for sane platforms where PATH is properly
    set.)
    d87b13ed
    History
    fbink: fix path in wallabako's caller
    Antoine Beaupré authored
    The implementation of on-screen display would frequently fail to
    run correctly, particularly when it would be started from udev. It
    seems that, from there, the PATH environment is just completely empty,
    which, naturally, makes it... hard for wallabako to find the fbink
    binary.
    
    It seems like my original implementation in 79745486 (implement basic
    fbink output (#49), 2023-06-09) already had this hack to try to add to
    PATH, but that didn't work: I suspect exec.Command doesn't look at the
    provided Env for the PATH environment. This is a bit counter-intuitive
    to me, but actually makes sense: Env is passed *to* the subprocess,
    but the PATH used is the one from the *calling* process.
    
    (I haven't actually confirmed this, but I can definitely confirm that
    fixing this in the script udev calls actually works. A golang-only fix
    would be to change wallabako's PATH directly, but that seems more
    intrusive and unnecessary for sane platforms where PATH is properly
    set.)