How To Apply Manual Change to Config File?

johnywhy · 2015-05-09 20:19:52

hi

in the battery panel applet, if i set a command to run on critical level, the command is stored in /root/.config/xfce4/panel/battery-10.rc

...
command_on_critical=NEW-COMMAND
...

but, if i make a manual change to /root/.config/xfce4/panel/battery-10.rc, the change is NOT reflected in the battery applet properties

Therefor, after making a manual change to /root/.config/xfce4/panel/battery-10.rc, what command can i execute at a command-line to make that change take effect (without restarting the window manager).

thx!

Jerry3904 · 2015-05-09 20:41:01

Would this work?

xfce4-panel -r

johnywhy · 2015-05-09 21:59:08

Jerry3904 wrote:

xfce4-panel -r

thx, but nope. that had the opposite effect: it changed the config file to match the setting in the gui.

any other suggestions?

thx!

ToZ · 2015-05-09 22:02:11

I don't think you can. This plugin is written using the older rc configuration system (files) as opposed to the newer xfconf system - which allows for on-the-fly configuration changes.

johnywhy · 2015-05-09 22:25:54

i figured out how to do this:

- quit the panel with:
xfce4-panel -q

- apply the manual change to the config file.
- start the panel with:
xfce4-panel

the panel applet gets it's setting from the config file, and then saves it's setting to the config file when it terminates. Therefor, it cannot be running when the change is made to the config file.

Next question:
- how to terminate just the battery applet, instead of terminating the entire panel? I cannot find anything containing the name "battery" in task manager.

Thx!

Last edited by johnywhy (2015-05-09 22:47:41)

ToZ · 2015-05-09 22:52:33

That seems like alot of work to simply change a setting. How about if you took another approach to this problem.

What if you set the command to be to a script of your own, say "~/my_command". Set in the battery plugin gui to run this command. Now, inside of ~/my_command, you can enter whatever command you want run:

#!/bin/bash

# enter your command below
notify-send "Pending Doom!" "This computer is about to lose power..."

...and make sure this script file is set executable.

Then, if you ever want to change the command to be run, simply edit the script that you created. Or link it to another executable file.

johnywhy · 2015-05-09 23:30:07

Thx, but that does not achieve my goal.

Want to set critical action command programmatically, without touching GUI.

Thx, tho!

ToZ · 2015-05-09 23:51:45

You can programmatically change the contents of the script file. No need to touch the GUI. It will accomplish the same goal.

johnywhy · 2015-05-10 05:46:25

i may be misunderstanding you, but this part does not seem programmatic:

ToZ wrote:

set the command to be to a script of your own in the battery plugin gui

ToZ · 2015-05-10 12:58:50

In the battery monitor gui, you can set the "Critical Battery Action" to run a command, and in the next field, you can enter that command. You want to be able to change the command that is being run when the battery reaches critical power. Here is what I suggest:

Let's use two commands as examples:
1. mousepad -> (start the mousepad application)
2. notify-send "Pending Doom!" "This computer is about to lose power..." -> (send a notification)
...(of course, you would use the commands that you need, but we'll use these two for testing and illustration purposes.

In the battery monitor gui, in the command field, enter the command "/home/<user>/bscript" (where <user> is your username). So when the battery plugin detects critical battery power, it will run the command "/home/<user>/bscript".

Create the file bscript in your home directory with the following contents:

#!/bin/bash

COMMAND="mousepad"

exec "$COMMAND" &

...and make this file executable:

chmod +x bscript

Now, when the battery reaches critical power, the plugin will run /home/<user>/bscript, which in turn, will start up mousepad.

Now suppose you want to programatically change the command that is currently being run to something else. To do so, simply do a sed inline edit:

sed -i 's/^COMMAND.*/COMMAND="notify-send "Pending Doom!" "This computer is about to lose power..."/' bscript

...this will change the COMMAND= line in the script file to the second example. Or, you can also manually edit the file.

And now, when the battery reaches critical power, the plugin will run /home/<user>/bscript which in turn, will send out the notification. There is no need to start or restart the plugin, just change the contents of the script that is being run on critical battery.

johnywhy · 2015-05-10 17:37:51

Hi, thx, yes, I understood your suggestion the first time.

What I'd really like to find is a way to programmatically terminate and start the battery monitor. All I need, I think, is the name of the executable.

Thx!

ToZ · 2015-05-10 18:18:54

Ok, scratch the elegant method.

xfce4-panel plugins don't have executables. They are compiled into library files that are run by xfce4-panel. The library file you are looking for is called libbattery.so:

ps -ef | grep libbattery.so | grep -v grep

You could try killing it with a SIGKILL command:

kill -9 $(ps -ef | grep libbattery.so | grep -v grep | awk '{ print $2 }')

That should kill the process (preventing the write out of the config file) and xfce4-panel should restart it immediately at which point it will read the config file.

YMMV.

johnywhy · 2015-05-10 18:40:35

fantastic! thank you very much for the info and solution!

now trying to understand your kill command.

kill -9 $(ps -ef | grep libbattery.so | grep -v grep | awk '{ print $2 }')

-9 is the action, which = kill.
ps -ef returns a full listing of all processes, all columns. That's piped into:
grep libbattery.so looks for 'libbattery.so' in the process list. This will output two processes: the libbattery.so process, and this grep command (because it also contains the string "libbattery.so". That's piped into:
grep -v grep This command removes this grep process from the list, leaving only the libbattery.so process. That's piped into:
awk '{ print $2 }') i think awk is printing the second column piped into it? The output of the awk fragment is 26727, the process ID of the battery monitor. So, awk is pulling the 2nd column from the previous grep command.

Wow, i figured it out big_smile These sites helped me:
http://linux.die.net/man/1/kill
http://explainshell.com/explain?cmd=kil … 42+}%27%29
http://explainshell.com/explain?cmd=ps% … 242%20}%27

i appreciate your previous clever redirect method, but not quite right for my need.

new issue: sometimes (not every time), i get:

Plugin "Battery Monitor" unexpectedly left the panel, do you want to restart it?

is this preventable?

many thanks!

Last edited by johnywhy (2015-05-10 19:53:36)

ToZ · 2015-05-10 20:21:40

johnywhy wrote:

i appreciate your previous clever redirect method, but not quite right for my need.

^^^This, and...

new issue: sometimes (not every time), i get:
Plugin "Battery Monitor" unexpectedly left the panel, do you want to restart it?
is this preventable?

...this. Which is why I suggested the previous method. This method is unreliable and not the way to force an application to re-read its configuration. You will get errors.

The other option is to open a bug report/enhancement request with the developer to convert the plugin to use the xfconf backend.

johnywhy · 2015-05-10 20:52:47

ToZ wrote:

not the way to force an application to re-read its configuration.

what is "the way"? happy to use a more correct method if available. Again, looking for a non-gui method. This looks like the only non-gui method available. What is the correct non-gui method to make libbattery.so re-read it's configuration?

The other option is to open a bug report/enhancement request with the developer to convert the plugin to use the xfconf backend.

well, that sounds like a great idea, but how will that help with this problem? won't that method still require restarting the battery monitor in order to reread it's config from xfconf? Will xfconf enable libbattery.so to reread it's config without restarting?

thx!

Last edited by johnywhy (2015-05-10 23:16:07)

johnywhy · 2015-05-10 20:55:35

Deleted to focus on post above

Last edited by johnywhy (2015-05-10 21:23:31)

ToZ · 2015-05-10 23:24:37

johnywhy wrote:

Please tell: under what circumstances will the kill command above fail to terminate the process?

It will terminate the process, just not cleanly. It doesn't allow the application to properly shutdown. Applications _may_ behave strangely if not allowed to properly shut down.

what is "the way"? happy to use a more correct method if available. Again, looking for a non-gui method. This looks like the only non-gui method available.

Earlier in this thread, I outlined a non-gui method that will meet your needs without needing to kill and restart the panel plugin.

Please tell: What is the correct non-gui method to make libbattery.so re-read it's configuration.

One does not exist. This functionality was not programmed into the plugin.

Please tell: what other alerts or errors may i receive?

The one that you are seeing now is likely the result of killing the plugin and not allowing it to shutdown properly. It also might be the result of an improperly formatted configuration file (e.g. the entered command is incorrect)

The other option is to open a bug report/enhancement request with the developer to convert the plugin to use the xfconf backend.
well, that sounds like a great idea, but how will that help with this problem? won't that method still require restarting the battery monitor in order to reread it's config from xconf?

It won't help with your immediate issue. Its a long-term solution. And no, it won't require the restart of the plugin to re-read the configuration.

Please tell: Will xfconf enable libbattery.so to reread it's config without restarting?

If programmed properly, yes. It will expose an xfconf interface to the configuration files that can be changed on the fly (like other plugins that use xfconf). However, the developer in charge of this plugin will need to make that change. Or someone with programming knowledge to submit a patch.

Consider this example - the Windows Buttons plugin. With the plugin enabled and running, I can enter (in my case):

xfconf-query -c xfce4-panel -p /plugins/plugin-7/include-all-workspaces -s true

...to turn on the display of buttons from all workspaces. The effect is instantaneous. That is the benefit of xfconfd.

johnywhy · 2015-05-10 23:58:50

ToZ wrote:

Applications _may_ behave strangely if not allowed to properly shut down.

understood. is there a specific strange behavior with this specific application that you're aware of, aside from this alert? Or, you're just speaking in general, generic terms, and not about this specific plugin?

ToZ wrote:

Earlier in this thread, I outlined a non-gui method that will meet your needs without needing to kill and restart the panel plugin.

unless i'm misunderstanding, your suggestion was not a "non-gui" method. Your steps require interacting with the gui:

ToZ wrote:

In the battery monitor gui, in the command field, enter the command

By "non-gui method", i mean a method with does not involve interacting with the gui.

ToZ wrote:

What is the correct non-gui method to make libbattery.so re-read it's configuration.
One does not exist. This functionality was not programmed into the plugin.

actually, i think that's not completely correct-- the way that's programmed into the plugin is to read its config when it starts. So, indirectly, by forcing the app to restart, it will re-read it's config. I realize that's not a "direct" way, but it works.

ToZ wrote:

what other alerts or errors may i receive?
The one that you are seeing now is likely the result of killing the plugin and not allowing it to shutdown properly. It also might be the result of an improperly formatted configuration file (e.g. the entered command is incorrect)

no offense, but i think you're incorrect. This alert appears to be generated by the panel, not the battery monitor (if the battery monitor is terminated, then it would not be able to generate an alert-- it must be coming from a different xfce process). I notice it only happens if i terminate the battery twice in quick succession-- if i wait a while and terminate the battery monitor again, i do not get the alert (even with no change in the config file). so there must be a timer in said process, which tries to detect apps that repeatedly terminate (indicating a bug or corruption).

thx!

ToZ · 2015-05-11 01:34:57

johnywhy wrote:

ToZ wrote:
Applications _may_ behave strangely if not allowed to properly shut down.
understood. is there a specific strange behavior with this specific application that you're aware of, aside from this alert? Or, you're just speaking in general, generic terms, and not about this specific plugin?

I'm speaking in general terms. Its risky when you don't allow an application to properly shutdown as you don't allow it to properly close down (save files, release memory, etc). I have not analyzed this plugin to see what exactly the effects would be in it's specific case.

ToZ wrote:
Earlier in this thread, I outlined a non-gui method that will meet your needs without needing to kill and restart the panel plugin.
unless i'm misunderstanding, your suggestion was not a "non-gui" method. Your steps require interacting with the gui:
ToZ wrote:
In the battery monitor gui, in the command field, enter the command
By "non-gui method", i mean a method with does not involve interacting with the gui.

The only gui piece would be to set the command to point to your own script. From there on in, you wouldn't need to touch the gui. But if your goal is to not touch the gui at all, ever, then I guess you could dump a pre-configured rc file in the proper location before you add the plugin to the panel. But I'm speculating - I don't know whether this would work.

ToZ wrote:
What is the correct non-gui method to make libbattery.so re-read it's configuration.
One does not exist. This functionality was not programmed into the plugin.
actually, i think that's not completely correct-- the way that's programmed into the plugin is to read its config when it starts. So, indirectly, by forcing the app to restart, it will re-read it's config. I realize that's not a "direct" way, but it works.

In a way, I guess yes. But probably not the way the developer intended it to.

ToZ wrote:
what other alerts or errors may i receive?
The one that you are seeing now is likely the result of killing the plugin and not allowing it to shutdown properly. It also might be the result of an improperly formatted configuration file (e.g. the entered command is incorrect)
no offense, but i think you're incorrect. This alert appears to be generated by the panel, not the battery monitor (if the battery monitor is terminated, then it would not be able to generate an alert-- it must be coming from a different xfce process). I notice it only happens if i terminate the battery twice in quick succession-- if i wait a while and terminate the battery monitor again, i do not get the alert (even with no change in the config file). so there must be a timer in said process, which tries to detect apps that repeatedly terminate (indicating a bug or corruption).

Yes, the panel manages the plugins, so if there is a problem with a plugin, I assume a message is sent to the panel and it deals with it. The end result is the same. Try setting a non-existent command in the command parameter in the config file - it will crash as well. So the app must be doing some sort of command validity checking during startup.

I'm not sure what more I can offer in the way of advice. If you can find a way to intercept the reload of the plugin and change the config settings, then kudos to you. All I can say is that from my understanding of this plugin, it was not designed to allow for on-the-fly programmatic changes to the configuration like some of the other plugins are.

johnywhy · 2015-05-11 20:35:41

thx for all help.

here's an extension i wrote for xfce battery monitor, based on this info.
http://murga-linux.com/puppy/viewtopic.php?t=99097

thx!

MountainDewManiac · 2015-05-12 00:43:26

It's good that you're contributing to the Xfce world.

I feel like I should point out, though, that with the current (4.12) and previous (4.10) version of Xfce, when my laptop reaches low battery level (I think I have it set for 10%, but it might be a little higher or lower), it'll run the "exit/logout app" popup and I have the ability - and, it appears, enough remaining battery capacity - to save my work, close my applications/files, and still shut down before any kind of "hard power-off" point approaches. The current method doesn't have that friendly, Windows-like 60-second popup though... OtOH, it doesn't come with the "gotcha" (your term, I believe) /FAIL message popup thing, either. Still, it gives the user another option, another way to do something. Seems like that's a plus in linux, so bravo!

Regards,
MDM

Last edited by MountainDewManiac (2015-05-12 00:43:53)

johnywhy · 2015-05-12 03:04:27

MountainDewManiac wrote:

It's good that you're contributing to the Xfce world.

thx! it's the most powerful, user-friendly light wm.

MountainDewManiac wrote:

with the current (4.12) and previous (4.10) version of Xfce, when my laptop reaches low battery level, it'll run the "exit/logout app" popup

i don't get that. i have:

when my battery runs out, i get a hard shutdown.

re the gotcha, that only happens if someone installs and then uninstalls within 60 seconds (which hopefully they won't usually do). However, i bet there's a way to prevent that alert, perhaps someone here knows?

thx!

Last edited by johnywhy (2015-05-12 04:11:36)

Sideburns · 2015-05-12 06:36:58

One thing nobody's mentioned is that /root is the home directory for root, not a place where default configurations are set. (Those are usually somewhere in /etc.) Thus, by changing the file /root/.config/xfce4/panel/battery-10.rc, you're changing what happens when root is logged into an Xfce session (not a Good Idea) not the default for new users.

johnywhy · 2015-05-12 07:47:49

Sideburns wrote:

/root is the home directory for root, not a place where default configurations are set.

Sideburns, Thx for this feedback. I will inquire on the Puppy forum, since puppy has some different than other linuxes.

For example, most or all puppy distros operate in root mode-- there are no other users.

Question, in other linuxes, does xfce place config files someplace in etc for all/new users?

Thx

Sideburns · 2015-05-12 13:36:35

Yes, I'm familiar with Puppy; I didn't realize that was what you were using.

Xfce Forum

Sub domains

#1 2015-05-09 20:19:52

How To Apply Manual Change to Config File?

#2 2015-05-09 20:41:01

Re: How To Apply Manual Change to Config File?

#3 2015-05-09 21:59:08

Re: How To Apply Manual Change to Config File?

#4 2015-05-09 22:02:11

Re: How To Apply Manual Change to Config File?

#5 2015-05-09 22:25:54

Re: How To Apply Manual Change to Config File?

#6 2015-05-09 22:52:33

Re: How To Apply Manual Change to Config File?

#7 2015-05-09 23:30:07

Re: How To Apply Manual Change to Config File?

#8 2015-05-09 23:51:45

Re: How To Apply Manual Change to Config File?

#9 2015-05-10 05:46:25

Re: How To Apply Manual Change to Config File?

#10 2015-05-10 12:58:50

Re: How To Apply Manual Change to Config File?

#11 2015-05-10 17:37:51

Re: How To Apply Manual Change to Config File?

#12 2015-05-10 18:18:54

Re: How To Apply Manual Change to Config File?

#13 2015-05-10 18:40:35

Re: How To Apply Manual Change to Config File?

#14 2015-05-10 20:21:40

Re: How To Apply Manual Change to Config File?

#15 2015-05-10 20:52:47

Re: How To Apply Manual Change to Config File?

#16 2015-05-10 20:55:35

Re: How To Apply Manual Change to Config File?

#17 2015-05-10 23:24:37

Re: How To Apply Manual Change to Config File?

#18 2015-05-10 23:58:50

Re: How To Apply Manual Change to Config File?

#19 2015-05-11 01:34:57

Re: How To Apply Manual Change to Config File?

#20 2015-05-11 20:35:41

Re: How To Apply Manual Change to Config File?

#21 2015-05-12 00:43:26

Re: How To Apply Manual Change to Config File?

#22 2015-05-12 03:04:27

Re: How To Apply Manual Change to Config File?

#23 2015-05-12 06:36:58

Re: How To Apply Manual Change to Config File?

#24 2015-05-12 07:47:49

Re: How To Apply Manual Change to Config File?

#25 2015-05-12 13:36:35

Re: How To Apply Manual Change to Config File?

Board footer