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 <d...@randomstring.org> > To: Esteban L <este...@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>
