LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   every hour run a bash function inside a bash shell (https://www.linuxquestions.org/questions/programming-9/every-hour-run-a-bash-function-inside-a-bash-shell-4175675887/)

Skaperen 05-25-2020 02:43 PM

every hour run a bash function inside a bash shell
 
i know how to define bash functions. i'd like to have a bash function run inside a bash process every hour. well, maybe every 20 minutes. too bad cron is a separate process.

jailbait 05-25-2020 03:20 PM

I suggest that you run a continuous loop with a sleep function in it. See:

man sleep

-----------------
Steve Stites

Skaperen 05-25-2020 04:54 PM

that would block the shell continuously. i want to limit blocking the shell to the time it takes for the function to run.

ntubski 05-25-2020 05:56 PM

You could tell the scheduled other process to signal your running process, and call the function you want from a signal handler.

https://www.gnu.org/software/bash/ma...tml#index-trap

chrism01 05-25-2020 08:43 PM

It'd be good to know exactly what you are trying to achieve and why.
There may be a lateral soln.

rtmistler 05-25-2020 08:53 PM

Quote:

Originally Posted by Skaperen (Post 6127266)
that would block the shell continuously.

I don't agree. It's a process. Doesn't starve the system.

wpeckham 05-25-2020 09:23 PM

Quote:

Originally Posted by Skaperen (Post 6127218)
i know how to define bash functions. i'd like to have a bash function run inside a bash process every hour. well, maybe every 20 minutes. too bad cron is a separate process.

If I understand you correctly, you want to create a bash script to replicate the functionality of cron or at. Why would you want to do that? What advantage obtains?

Skaperen 05-26-2020 08:57 PM

i want to routinely check the environment variables for change in my interactive shell. once an hour or so is good for now.

rknichols 05-26-2020 10:32 PM

The environment variables within a process will never change from their inherited values unless that process itself changes them. Within an interactive shell, the only way to change them would be by a command line direct assignment or by a sourced (not simply executed) script. There is no notion of some "global environment" that other processes can chamge at will and have those changes seen by all.

pan64 05-27-2020 02:22 AM

Quote:

Originally Posted by Skaperen (Post 6127734)
i want to routinely check the environment variables for change in my interactive shell. once an hour or so is good for now.

Why? And what should be the result?

In bash you can call a function in PS1 too (although it is not efficient and not really practical).

wpeckham 05-27-2020 06:42 AM

To do that you might have to get a bit fancy. It is not a function running form a script that you want. You want something like a function or script running from each new display of the default command line prompt, or that you manually call on occasion. There is no other way for it to have access to the environment you are running in that for you to run it in your session somehow. (Otherwise it gets it's own environment, which may be different from the one you want to monitor.)

Skaperen 05-27-2020 06:32 PM

there are a couple new environment variables showing up that i do not recognize (any of my shell functions exporting). i have grepped every file for their names and nothing is found. these are not getting set when the shell first starts up (or i could blame myown .bashrc file). so they must be getting set later. by being alerted to this, my command history might still show me the possibilities to let me eventually narrow down the culprit. i'm concerned about these variables because they resemble some confidential/personal data. they are not exact, but close enough to raise eyebrows.

i do use lots of shell functions, many in lieu of aliases, many longer.

Skaperen 05-27-2020 09:42 PM

got a solution. save the shell PID in a file [echo $$ >shell.pid]. cron a script that gets the PID from that file [if it does not exist, just quietly exit]. then it grabs the environment variables and saves them [tr '\0' '\012' </proc/${pid}/environ|grep =|sort >/home/phil/$(date +%Y_%m%d_%H%M)] in a unique file. then i can scan them later. the next version would look for those names and if it sees them, send me a message.

rnturn 05-28-2020 05:00 AM

Quote:

Originally Posted by Skaperen (Post 6128110)
got a solution. save the shell PID in a file [echo $$ >shell.pid]. cron a script that gets the PID from that file [if it does not exist, just quietly exit]. then it grabs the environment variables and saves them [tr '\0' '\012' </proc/${pid}/environ|grep =|sort >/home/phil/$(date +%Y_%m%d_%H%M)] in a unique file. then i can scan them later. the next version would look for those names and if it sees them, send me a message.

I was going to suggest something very similar: periodically grabbing the contents of /proc/$$/environ and saving it in a file, say, "my.env". Then wake up some time later, rename "my.env.prev" and grab the environment, again, into "my.env"). Then use diff(1), md5sum(1), or whatever you like to detect a change between the two snapshots, squawking if a change is seen---perhaps using diff(1) and emailing yourself the changes, repeating ad nauseum. But... when I try that: grabbing a snapshot, defining a new environment variable, and grabbing another snapshot, diff(1) shows no difference between the two snapshots. Hmm...

Back to the drawing board...

rnturn 05-28-2020 05:04 AM

Quote:

Originally Posted by wpeckham (Post 6127848)
To do that you might have to get a bit fancy. It is not a function running form a script that you want. You want something like a function or script running from each new display of the default command line prompt, or that you manually call on occasion. There is no other way for it to have access to the environment you are running in that for you to run it in your session somehow. (Otherwise it gets it's own environment, which may be different from the one you want to monitor.)

You could kick the script off, passing your PID to it, and run it in the background, via "at", via nohup (maybe) and grab the environment out of /proc/<PID>/environ. However, I tried that and saw no differences after making a change to the environment (see other reply: #14).


All times are GMT -5. The time now is 03:53 PM.