Triggering a gui from an acpi event











up vote
2
down vote

favorite












I've made a tkinter app to handle the power button press, but it doesn't launch when it should. Although if I use echo hello>>~/junk as the acpi action, it adds a hello to junk for every power button press. Adding an exec or a dot before the action command (to execute it in the current shell) didn't help. How can I make it work?



Edit:



Ok I got that to work with the help of mikejonesey, but one more issue appeared after that. The script is called with root privilages, even with the suid bit set on the script, so I have to enter the root passwd at the xlock screen to resume.



Edit 2:



It looks like I can launch the app from an acpi events file like this one:
event=button/power PBTN
action=export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority &&/home/saga/bin/shutdownprompt



but not from a handler script called from an event file:



button/power )
if [ "$2" = "PBTN" ];then
export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority && /home/saga/shutdownprompt;
fi
;;



This is a clipping from main handler script called on every key press. What is the problem here?










share|improve this question















migrated from meta.unix.stackexchange.com Oct 23 '16 at 19:35


This question came from our discussion, support, and feature requests site for users of Linux, FreeBSD and other Un*x-like operating systems.



















    up vote
    2
    down vote

    favorite












    I've made a tkinter app to handle the power button press, but it doesn't launch when it should. Although if I use echo hello>>~/junk as the acpi action, it adds a hello to junk for every power button press. Adding an exec or a dot before the action command (to execute it in the current shell) didn't help. How can I make it work?



    Edit:



    Ok I got that to work with the help of mikejonesey, but one more issue appeared after that. The script is called with root privilages, even with the suid bit set on the script, so I have to enter the root passwd at the xlock screen to resume.



    Edit 2:



    It looks like I can launch the app from an acpi events file like this one:
    event=button/power PBTN
    action=export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority &&/home/saga/bin/shutdownprompt



    but not from a handler script called from an event file:



    button/power )
    if [ "$2" = "PBTN" ];then
    export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority && /home/saga/shutdownprompt;
    fi
    ;;



    This is a clipping from main handler script called on every key press. What is the problem here?










    share|improve this question















    migrated from meta.unix.stackexchange.com Oct 23 '16 at 19:35


    This question came from our discussion, support, and feature requests site for users of Linux, FreeBSD and other Un*x-like operating systems.

















      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      I've made a tkinter app to handle the power button press, but it doesn't launch when it should. Although if I use echo hello>>~/junk as the acpi action, it adds a hello to junk for every power button press. Adding an exec or a dot before the action command (to execute it in the current shell) didn't help. How can I make it work?



      Edit:



      Ok I got that to work with the help of mikejonesey, but one more issue appeared after that. The script is called with root privilages, even with the suid bit set on the script, so I have to enter the root passwd at the xlock screen to resume.



      Edit 2:



      It looks like I can launch the app from an acpi events file like this one:
      event=button/power PBTN
      action=export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority &&/home/saga/bin/shutdownprompt



      but not from a handler script called from an event file:



      button/power )
      if [ "$2" = "PBTN" ];then
      export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority && /home/saga/shutdownprompt;
      fi
      ;;



      This is a clipping from main handler script called on every key press. What is the problem here?










      share|improve this question















      I've made a tkinter app to handle the power button press, but it doesn't launch when it should. Although if I use echo hello>>~/junk as the acpi action, it adds a hello to junk for every power button press. Adding an exec or a dot before the action command (to execute it in the current shell) didn't help. How can I make it work?



      Edit:



      Ok I got that to work with the help of mikejonesey, but one more issue appeared after that. The script is called with root privilages, even with the suid bit set on the script, so I have to enter the root passwd at the xlock screen to resume.



      Edit 2:



      It looks like I can launch the app from an acpi events file like this one:
      event=button/power PBTN
      action=export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority &&/home/saga/bin/shutdownprompt



      but not from a handler script called from an event file:



      button/power )
      if [ "$2" = "PBTN" ];then
      export DISPLAY=:0 && export XAUTHORITY=/home/saga/.Xauthority && /home/saga/shutdownprompt;
      fi
      ;;



      This is a clipping from main handler script called on every key press. What is the problem here?







      x11 acpi tcl






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Oct 26 '16 at 16:59

























      asked Oct 23 '16 at 18:26









      saga

      776220




      776220




      migrated from meta.unix.stackexchange.com Oct 23 '16 at 19:35


      This question came from our discussion, support, and feature requests site for users of Linux, FreeBSD and other Un*x-like operating systems.






      migrated from meta.unix.stackexchange.com Oct 23 '16 at 19:35


      This question came from our discussion, support, and feature requests site for users of Linux, FreeBSD and other Un*x-like operating systems.
























          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote













          you need to add some stuff to use X;



          I use these in a cronjob (it's the same thing...)



          #*/15 * * * *   export DISPLAY=:0.0 && export XAUTHORITY=/home/mike/.Xauthority && /home/mike/bin/defunct-check.sh


          This should work from any script.






          share|improve this answer





















          • Works on single-user systems, but woefully inadequate in multi-user environments.
            – Wyatt8740
            Sep 21 at 16:45










          • @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
            – mikejonesey
            Sep 24 at 23:00










          • I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
            – Wyatt8740
            Sep 27 at 17:27




















          up vote
          0
          down vote













          It seems like there should be an easy solution to this problem. I myself was trying to do something similar: run a screen capture program (flameshot) when a keyboard button is pressed.



          In the end, the solution that worked for me was to create a FIFO (named pipe) in my home directory called .acpi_execute.pipe. I then use the following script, called .acpi_execute.



          #!/usr/bin/bash

          while true ; do
          while IFS='' read command ; do
          $command
          done < ~/.acpi_execute.pipe
          done


          I prefer i3 over GNOME, KDE, etc, due to it's performance (very lightweight) and tiling nature. At the bottom of my i3 configuration file ~/.config/i3/config I have:



          exec ~/.acpi_execute


          This allows the script to be run whenever my Desktop Environment starts (whether directly on the machine or via a remote VNC connection).



          Be aware that the above has security implications. For example, if anyone can write to the above pipe, they can execute arbitary commands as you. This would obviously be bad. Giving the FIFO 600 permissions, owned by yourself, reduces this risk. You can also limit the commands possible. That is, don't execute $command, but rather the specific command you want (e.g., flameshot gui).






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f318375%2ftriggering-a-gui-from-an-acpi-event%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            2
            down vote













            you need to add some stuff to use X;



            I use these in a cronjob (it's the same thing...)



            #*/15 * * * *   export DISPLAY=:0.0 && export XAUTHORITY=/home/mike/.Xauthority && /home/mike/bin/defunct-check.sh


            This should work from any script.






            share|improve this answer





















            • Works on single-user systems, but woefully inadequate in multi-user environments.
              – Wyatt8740
              Sep 21 at 16:45










            • @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
              – mikejonesey
              Sep 24 at 23:00










            • I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
              – Wyatt8740
              Sep 27 at 17:27

















            up vote
            2
            down vote













            you need to add some stuff to use X;



            I use these in a cronjob (it's the same thing...)



            #*/15 * * * *   export DISPLAY=:0.0 && export XAUTHORITY=/home/mike/.Xauthority && /home/mike/bin/defunct-check.sh


            This should work from any script.






            share|improve this answer





















            • Works on single-user systems, but woefully inadequate in multi-user environments.
              – Wyatt8740
              Sep 21 at 16:45










            • @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
              – mikejonesey
              Sep 24 at 23:00










            • I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
              – Wyatt8740
              Sep 27 at 17:27















            up vote
            2
            down vote










            up vote
            2
            down vote









            you need to add some stuff to use X;



            I use these in a cronjob (it's the same thing...)



            #*/15 * * * *   export DISPLAY=:0.0 && export XAUTHORITY=/home/mike/.Xauthority && /home/mike/bin/defunct-check.sh


            This should work from any script.






            share|improve this answer












            you need to add some stuff to use X;



            I use these in a cronjob (it's the same thing...)



            #*/15 * * * *   export DISPLAY=:0.0 && export XAUTHORITY=/home/mike/.Xauthority && /home/mike/bin/defunct-check.sh


            This should work from any script.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 23 '16 at 20:42









            mikejonesey

            1,362415




            1,362415












            • Works on single-user systems, but woefully inadequate in multi-user environments.
              – Wyatt8740
              Sep 21 at 16:45










            • @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
              – mikejonesey
              Sep 24 at 23:00










            • I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
              – Wyatt8740
              Sep 27 at 17:27




















            • Works on single-user systems, but woefully inadequate in multi-user environments.
              – Wyatt8740
              Sep 21 at 16:45










            • @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
              – mikejonesey
              Sep 24 at 23:00










            • I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
              – Wyatt8740
              Sep 27 at 17:27


















            Works on single-user systems, but woefully inadequate in multi-user environments.
            – Wyatt8740
            Sep 21 at 16:45




            Works on single-user systems, but woefully inadequate in multi-user environments.
            – Wyatt8740
            Sep 21 at 16:45












            @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
            – mikejonesey
            Sep 24 at 23:00




            @Wyatt8740 people like you are why I stopped posting here... nothing of value to add, only negativity... add your own solution if you have a better one... and you forgot the multi-user multi-display system...
            – mikejonesey
            Sep 24 at 23:00












            I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
            – Wyatt8740
            Sep 27 at 17:27






            I'm not writing an answer because I don't have an answer. I found this post because I was also searching for an answer. BUT I'm making a comment as a warning to others who decide to use this solution, to remind them it's not multi-user safe. If you're the only one on the computer, by all means go ahead. (Also I appreciate being called worthless. Real mature.)
            – Wyatt8740
            Sep 27 at 17:27














            up vote
            0
            down vote













            It seems like there should be an easy solution to this problem. I myself was trying to do something similar: run a screen capture program (flameshot) when a keyboard button is pressed.



            In the end, the solution that worked for me was to create a FIFO (named pipe) in my home directory called .acpi_execute.pipe. I then use the following script, called .acpi_execute.



            #!/usr/bin/bash

            while true ; do
            while IFS='' read command ; do
            $command
            done < ~/.acpi_execute.pipe
            done


            I prefer i3 over GNOME, KDE, etc, due to it's performance (very lightweight) and tiling nature. At the bottom of my i3 configuration file ~/.config/i3/config I have:



            exec ~/.acpi_execute


            This allows the script to be run whenever my Desktop Environment starts (whether directly on the machine or via a remote VNC connection).



            Be aware that the above has security implications. For example, if anyone can write to the above pipe, they can execute arbitary commands as you. This would obviously be bad. Giving the FIFO 600 permissions, owned by yourself, reduces this risk. You can also limit the commands possible. That is, don't execute $command, but rather the specific command you want (e.g., flameshot gui).






            share|improve this answer

























              up vote
              0
              down vote













              It seems like there should be an easy solution to this problem. I myself was trying to do something similar: run a screen capture program (flameshot) when a keyboard button is pressed.



              In the end, the solution that worked for me was to create a FIFO (named pipe) in my home directory called .acpi_execute.pipe. I then use the following script, called .acpi_execute.



              #!/usr/bin/bash

              while true ; do
              while IFS='' read command ; do
              $command
              done < ~/.acpi_execute.pipe
              done


              I prefer i3 over GNOME, KDE, etc, due to it's performance (very lightweight) and tiling nature. At the bottom of my i3 configuration file ~/.config/i3/config I have:



              exec ~/.acpi_execute


              This allows the script to be run whenever my Desktop Environment starts (whether directly on the machine or via a remote VNC connection).



              Be aware that the above has security implications. For example, if anyone can write to the above pipe, they can execute arbitary commands as you. This would obviously be bad. Giving the FIFO 600 permissions, owned by yourself, reduces this risk. You can also limit the commands possible. That is, don't execute $command, but rather the specific command you want (e.g., flameshot gui).






              share|improve this answer























                up vote
                0
                down vote










                up vote
                0
                down vote









                It seems like there should be an easy solution to this problem. I myself was trying to do something similar: run a screen capture program (flameshot) when a keyboard button is pressed.



                In the end, the solution that worked for me was to create a FIFO (named pipe) in my home directory called .acpi_execute.pipe. I then use the following script, called .acpi_execute.



                #!/usr/bin/bash

                while true ; do
                while IFS='' read command ; do
                $command
                done < ~/.acpi_execute.pipe
                done


                I prefer i3 over GNOME, KDE, etc, due to it's performance (very lightweight) and tiling nature. At the bottom of my i3 configuration file ~/.config/i3/config I have:



                exec ~/.acpi_execute


                This allows the script to be run whenever my Desktop Environment starts (whether directly on the machine or via a remote VNC connection).



                Be aware that the above has security implications. For example, if anyone can write to the above pipe, they can execute arbitary commands as you. This would obviously be bad. Giving the FIFO 600 permissions, owned by yourself, reduces this risk. You can also limit the commands possible. That is, don't execute $command, but rather the specific command you want (e.g., flameshot gui).






                share|improve this answer












                It seems like there should be an easy solution to this problem. I myself was trying to do something similar: run a screen capture program (flameshot) when a keyboard button is pressed.



                In the end, the solution that worked for me was to create a FIFO (named pipe) in my home directory called .acpi_execute.pipe. I then use the following script, called .acpi_execute.



                #!/usr/bin/bash

                while true ; do
                while IFS='' read command ; do
                $command
                done < ~/.acpi_execute.pipe
                done


                I prefer i3 over GNOME, KDE, etc, due to it's performance (very lightweight) and tiling nature. At the bottom of my i3 configuration file ~/.config/i3/config I have:



                exec ~/.acpi_execute


                This allows the script to be run whenever my Desktop Environment starts (whether directly on the machine or via a remote VNC connection).



                Be aware that the above has security implications. For example, if anyone can write to the above pipe, they can execute arbitary commands as you. This would obviously be bad. Giving the FIFO 600 permissions, owned by yourself, reduces this risk. You can also limit the commands possible. That is, don't execute $command, but rather the specific command you want (e.g., flameshot gui).







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 28 at 3:55









                magnus

                18917




                18917






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f318375%2ftriggering-a-gui-from-an-acpi-event%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Accessing regular linux commands in Huawei's Dopra Linux

                    Can't connect RFCOMM socket: Host is down

                    Kernel panic - not syncing: Fatal Exception in Interrupt