Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Substitute for $pre_exec for 2.0.0pre and higher? #62

Closed
andreas--e opened this issue Aug 24, 2014 · 15 comments
Closed

Substitute for $pre_exec for 2.0.0pre and higher? #62

andreas--e opened this issue Aug 24, 2014 · 15 comments
Assignees
Labels
Stale Issue that requires attention because it hasn't been updated for over a year

Comments

@andreas--e
Copy link

Well, I've just encountered by testing my fresh build with some old .conkyrc config files, that $pre_exec got removed at some point.
Why, actually?

$exec and friends do NOT do what I want, because I really only want to execute a certain shell command ONCE.
And $pre_exec was perfect for this task. So I wonder why the decision got made to remove a great feature that has been implemented since 2004.

@andreas--e andreas--e changed the title Substituting $pre_exec for 2.0.0pre and higher? Substitute for $pre_exec for 2.0.0pre and higher? Aug 24, 2014
@Tucos
Copy link

Tucos commented Aug 24, 2014

You should note that 2.0.0pre is pretty much a rewrite, rather than a
continuation of conky. That said, $pre_exec was removed in commit b96f112,
with the following reasoning: "I also removed the $pre_exec variable,
because one can use lua to generate the config on the startup, if one wants
to.".

@andreas--e
Copy link
Author

Frankly, I did read about this reasoning, but it made not the slightest sense to me. Generate what? How? Why? Before removing such important and well-established variable, I do expect from the person who removes it an explanation that goes beyond a terse, incomprehensibly "murmured" phrase. Since in fact it will mean that zillions of scripts worldwide will have to be modified.

And yes, I'm now "back" to 1.9.1 (git), since 2.0.0pre is way too far off: while I was able to transform my old .conkyrc to the new LUA format, I regret to say that transparency doesn't work anymore in v2pre, but shows black although this is not the actual black background color. (Changed it to something weird and it stayed black, hence I assumed the black is due to the malfunctioning transparency.)

@Tucos
Copy link

Tucos commented Aug 24, 2014

The sentence I quoted suggests that the thought was that the config is lua,
and thus lua can determine the value of that which used to be in $pre_exec
and then substitute it in TEXT. I agree that it should not have been
removed at all, and I'm not convinced it was thought through much either.
2.0.0 is/was more of a playground (especially back then).

@andreas--e
Copy link
Author

I agree that it should not have been removed at all

Which is already the gist of my plead. OK, if 2.0.0pre is really just meant to play around with ... no problem BUT then 1.9.1 ought to be 'master' and 2.0.0pre should be given something in the sense of 'experimental'. Because git newbies might simply mistake the 2.0.0pre for "latest devel" without being aware of the fact that seemingly "old" 1.9.1 is still actively developed; and above all that this is the only devel version meant to be used.
This is not a rant; it's a suggestion.

@Vincent-C
Copy link
Contributor

Forwarding a bug report (#791718) I received from a Debian user:

I noticed that the pre_exec variable has been removed, without
providing anything with an equivalent behavior.
This seems to be confirmed by:
#62
b96f112

The commit description says that the pre_exec variable has been removed
"because one can use lua to generate the config on the startup, if one
wants to".

Oh well, if one knew how to program in Lua, one could use Lua
to generate the config on startup!
I have currently no knowledge about Lua, so I am a bit lost without
some example in the documentation.

I failed to find any relevant explanation on how Lua could be used
to emulate the behavior of pre_exec...

My attempt (after converting my .conkyrc to the new Lua-based syntax)
is the following:

  $ cat .config/conky/conky.conf 
  -- vim: syntax=lua

  conky.config = {
    -- many settings...
    lua_startup_hook = 'conky_cow', -- append fortune said by a cow
    };

  -- stuff to be formatted on screen
  conky.text = [[
  a lot of stuff...
  ${color green}
  ]];

  function conky_cow()
      o = io.popen('fortune -s | cowsay', 'r')
      conky.text = conky.text .. o:read('*a')
  end

Unfortunately, it does not work and I do not know why.
In case you happen to know how I can emulate pre_exec, please
help me, and/or forward my bug report upstream.

Thanks for your time!

P.S.: my current workaround is to use execi with a long interval:

${color green}${execi 65000 fortune -s | cowsay}

It's much simpler than any Lua-based solution, but it does not
do exactly what I want...
I still wonder why pre_exec has been removed: it was so simple and
useful! :-(

@asl97
Copy link

asl97 commented Apr 28, 2017

@Vincent-C It's not working for your script is because the function ain't getting call.
from the quick few tests I did, it seem lua_startup_hook need the function to be in another file that is loaded using lua_load, not really sure how the hook function thingy all works cause I rather just directly use the config as lua since it is lua.

Basically just call the io.popen stuff and concat it into conky.text

conky.text = [[
a lot of stuff...
${color green}
]];

o = io.popen('fortune -s | cowsay', 'r')
conky.text = conky.text .. o:read('*a')

@labath Honestly, I am rather disappointed at how long this issue is left unaddressed, with no basic example since it's your commit which removed it.


everyone else: conky.text is just a string, http://lua-users.org/wiki/StringsTutorial
you can call a function and then concat the output to it. (see Concatenation in the tutorial)

an basic function which takes a string, execute it and return the output

require 'io'

function pre_exec(cmd)
    local handle = io.popen(cmd)
    local output = handle:read("*a")
    handle:close()
    return output
end

usage:

conky.text = pre_exec("lsb_release -sd || cat /etc/*release")..[[
${hr}
System $alignr ${nodename}
Kernel ${alignr} ${kernel}
-- additional stuff
]]

@lasers
Copy link
Contributor

lasers commented Aug 28, 2018

@su8 Thoughts?

@su8
Copy link
Collaborator

su8 commented Aug 28, 2018

You can close this issue, as the pre_exec option has been removed in favour of lua, which both people demonstrated usage examples. Even if we bring back the pre_exec the code will be the same, popen() call and read().

@lasers
Copy link
Contributor

lasers commented Aug 28, 2018

Okay, we'll close this issue. I think we need to document well-demonstrated examples in the man page sooner or later because this is still going to be confusing for everybody.

Then again, everybody I know is still confused with their life.

@lasers lasers closed this as completed Aug 28, 2018
@emk2203
Copy link

emk2203 commented Sep 4, 2018

Even after reading this a couple of times, I am still confused about where to put the function, how to concatenate so that the text is in the middle of the output, not just at the beginning, how to align the text as desired, how to format it and probably a lot more.

This leaves more open questions than it should.

@lasers lasers reopened this Sep 4, 2018
@plikhari
Copy link

plikhari commented Sep 5, 2018

This is a very trivial issue if you look at it - we want to run anything only once - it depends on a few issues::

  • the run duration of your conky.
  • How often do you restart the system - on a server - perhaps not for a looong time.
  • what is it that you run once and is it so resource hungry that if it runs again after a few days - it will give you digestive issues ?
  • starting a daemon

If you give ${execi} 100000 abc as the command - that is about 27.78 hours - that command will run once in that many hours.

This command or any LUA script will get evaluated every update_interval to figure out what is to be done with this line request.

  • in ${pre_exec} if the request has been seen before - then a holding variable will release that information already stored - otherwise the line is executed. There is no requirement for any time interval here.
  • in ${execi} an interval of time is required and every update_interval the time criteria is evaluated and the stored data is released if that value is not achieved.

Even though I have created a LUA alternative - (every conky function can be re-created in LUA with a very tiny overhead as compared to the original C++ code) - I no longer use it as I give a rather large time interval if ${pre_exec} is required.

use ${if_running} to check if a process is running and then let your command fire.

So if we agree - then ${pre_exec} is really not required.

@emk2203
Copy link

emk2203 commented Sep 5, 2018

@plikhari: You leave out the option that whatever is run with ${pre_exec} can only be run at startup. Trivial example: The time the computer was booted, or a sensor value at startup. If you re-run this, the value will be wrong.

If you really want to get rid of ${pre_exec}, although I cannot see a reason myself, please document the replacement option well. In this case, it should be option 1: ${execi} 10000 for things which can be repeated and option 2: whatever lua offers for things which should only run once, period.

Please keep in mind that most users of conky use it once to set their configuration and afterwards don't touch it for a very long time. This would help a lot of people out there. The new way is not as intuitive as the old option was.

@plikhari
Copy link

plikhari commented Sep 6, 2018

It is not that anyone wants to get rid of ${pre-exec} - it is already gone since 1.10.0 !!

You leave out the option that whatever is run with ${pre_exec} can only be run at startup.

That was the basic understanding for ${pre-exec}

A simple sh solution like this will also work - this is a rock bottom non LUA idea - also see #318 and why I do not use ${if_existing } - the file name used below is of my choosing - you may use whatever makes you happy:
${texecpi 10000 if [ ! -e /tmp/t001conky ]; then do something here; touch /tmp/t001conky; fi }

This will behave exactly like ${pre_exec}

  • will run at the start of your conky session.
  • each extra line you use this line on - you will need a new file name - so it can handle each event separately.
  • the numeric value for ${texecpi} can be 10 or 10000 - this will get evaluated each update_interval
  • it will only execute if /tmp/t01conky file does not exist. if you have a persistent /tmp folder - you may need to remove any such file(s) during system start in the conky start script. This ensures that even if you restart conky manually then - you can control if you want that file removed.

Copy link

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment, or this issue will be closed in 30 days.

@github-actions github-actions bot added the Stale Issue that requires attention because it hasn't been updated for over a year label Dec 17, 2023
Copy link

This issue was closed because it has been stalled for 30 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issue that requires attention because it hasn't been updated for over a year
Projects
None yet
Development

No branches or pull requests

9 participants