Web lists-archives.com

Re: notify-send script messed up my environment

On Tuesday 07 May 2019 07:17:11 pm Esteban L wrote:

> Thanks Mr. Ritter for sharing your expertise.
> I think the one thing that kind of mystifies me a little is the bus
> pipe. I am not familiar with that. A simple logout and log back in
> made my "environment" return to "normal."
> As you recommended, I simply ran the bash script on it's own. It
> worked fine. But, as I was debugging it, over time, it stopped
> working. Perhaps based, as you say, on nautilus getting confused.
> It frustrated me a bit. Because, at that point, not even running the
> script, alone, would work.
> I found a better solution. I found a python API that was coded
> specifically for this purpose, and I am more familiar with python than
> I am with Bash (though I admit, Bash probably is better suited for
> many tasks at this level). What's the saying about the "devil you
> know?" =)
> Thanks again!
> -----Original Message-----
> From: Dan Ritter <dsr@xxxxxxxxxxxxxxxx>
> To: Esteban L <esteban@xxxxxxxxxxxxxxx>
> Cc: debian-user <debian-user@xxxxxxxxxxxxxxxx>
> Subject: Re: notify-send script messed up my environment
> Date: Tue, 7 May 2019 18:12:01 -0400
> Esteban L wrote: 
> > I stepped in poo, and broke a cardinal sin, trying a script that I
> > didn't 100% understand. Now my environment is a little bit jacked.
> > Not
> > bad, still generally functioning. 
> >
> > I was trying to get notifications to run from the command line,
> > namely
> > crontab. No easy task, at least, not as easy as I would have
> > thought.
> >
> > I created and ran this script I found online:
> > #!/bin/bash
> > username=$(/usr/bin/whoami)
> > pid=$(pgrep -u $username nautilus)
> > dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$pid/environ | sed
> > /usr/bin/notify-send "$(today)"
> >
> > It seemed simple enough.
> >
> > It even worked a few half dozen times. Until, it didn't.
> >
> > I couldn't even run the script anymore, from the command line.
> > I get the following error:
> > grep: /proc/1700: Is a directory
> > grep: 25836/environ: No such file or directory
> >
> > I tried to "man" up but can't find anything on dbus, dbus_session
> > etc.
> >
> > I think it's as simple as messing up my environment.
> >
> > Can someone throw me a bone? I guess I could restart, and I assume
> > that
> > should work, but that doesn't really explain to me why it broke,
> > which
> > interests me more.
> Let's go through the script and see if we can explain it.
> #!/bin/bash
>     this is a bash script; please use /bin/bash to run it.
> username=$(/usr/bin/whoami)
>     run the command /usr/bin/whoami and put the output in the
>     variable "username"
> pid=$(pgrep -u $username nautilus)
>     run pgrep, look for a process named nautilus owned by that
>     username. Put the process ID in the variable "pid".
> dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$pid/environ | sed
>     look through the contents of the file in /proc/ (process id)
>     /environ and find the line which contains the word
>    DBUS_SESSION_BUS_ADDRESS. pipe that line through the stream
>    editor to remove a bunch of characters and leave the rest.
>    Put the value in the variable "dbus".
>     Make that "dbus" variable available to programs I run.
> /usr/bin/notify-send "$(today)"
>     Run "notify-send" with a value that comes from a program
>     called "today".
> Here are my suggestions:
> Test running 
>     /usr/bin/notify-send "Boo!"
> If you get a notification, it's working. If not, you have deeper
> problems.
> Test with echo.
>     After each variable assignment, run
>         echo $username
>     or
>         echo $pid
>     and so forth, as appropriate, to see what values you are
>     getting.
> Spaces and linebreaks are important.
> "Nautilus" is not a foolproof way of knowing which X session is
> wanted.
> $(today) probably doesn't do what you want.
> -dsr-
I've had a problem, I think with dbus that smells a bit like this.

I've a bash script that sends  inotifywait to watch the mail dir in /var, 
and when one of the files is closed after writing and incoming mail to 
it, returns to my script with the name of the file and sends kmail a 
dbus message to go get mail $name. At the same time it relaunches 
inotifywait to resume the watch. kmail goes and gets the mail, zeroing 
out the contents of /var/mail/$name. But on wheezy that got iffy after 
20+ days of uptime and I had to reboot to "clean" house or whatever was 
muching things up. In that 20 days, dbus probably handled 350 to 600 
cycles a day.  Now I haven't enough uptime on 64 bit stretch to test it 

Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>