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@randomstring.org>
> To: Esteban L <esteban@little-beak.com>
> Cc: debian-user <debian-user@lists.debian.org>
> 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
> > 's/DBUS_SESSION_BUS_ADDRESS=//' )
> > export DBUS_SESSION_BUS_ADDRESS=$dbus
> > /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
> 's/DBUS_SESSION_BUS_ADDRESS=//' )
> 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".
> export DBUS_SESSION_BUS_ADDRESS=$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
yet.
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>
Reply to: