Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #208374 > unrolled thread
| Started by | Esteban L <esteban@little-beak.com> |
|---|---|
| First post | 2019-05-07 23:30 +0200 |
| Last post | 2019-05-08 18:40 +0200 |
| Articles | 8 — 5 participants |
Back to article view | Back to linux.debian.user
notify-send script messed up my environment Esteban L <esteban@little-beak.com> - 2019-05-07 23:30 +0200
Re: notify-send script messed up my environment Dan Ritter <dsr@randomstring.org> - 2019-05-08 00:20 +0200
Re: notify-send script messed up my environment Esteban L <esteban@little-beak.com> - 2019-05-08 01:20 +0200
Re: notify-send script messed up my environment Gene Heskett <gheskett@shentel.net> - 2019-05-08 01:50 +0200
Re: notify-send script messed up my environment Dan Ritter <dsr@randomstring.org> - 2019-05-08 02:00 +0200
Re: notify-send script messed up my environment Gene Heskett <gheskett@shentel.net> - 2019-05-08 03:50 +0200
Re: notify-send script messed up my environment Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-08 14:40 +0200
Re: notify-send script messed up my environment David Wright <deblis@lionunicorn.co.uk> - 2019-05-08 18:40 +0200
| From | Esteban L <esteban@little-beak.com> |
|---|---|
| Date | 2019-05-07 23:30 +0200 |
| Subject | notify-send script messed up my environment |
| Message-ID | <xVfOW-fA-5@gated-at.bofh.it> |
Hello, 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. Thanks in advance, to anyone that can throw me a bone.
[toc] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2019-05-08 00:20 +0200 |
| Message-ID | <xVgBj-LU-3@gated-at.bofh.it> |
| In reply to | #208374 |
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-
[toc] | [prev] | [next] | [standalone]
| From | Esteban L <esteban@little-beak.com> |
|---|---|
| Date | 2019-05-08 01:20 +0200 |
| Message-ID | <xVhxn-1kX-1@gated-at.bofh.it> |
| In reply to | #208376 |
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-
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-05-08 01:50 +0200 |
| Message-ID | <xVi0p-1uG-1@gated-at.bofh.it> |
| In reply to | #208379 |
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>
[toc] | [prev] | [next] | [standalone]
| From | Dan Ritter <dsr@randomstring.org> |
|---|---|
| Date | 2019-05-08 02:00 +0200 |
| Message-ID | <xVia5-1yc-7@gated-at.bofh.it> |
| In reply to | #208380 |
Gene Heskett wrote: > 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. You're watching /var/mail/gheskett for new mail? Kmail can probably do that by itself. https://docs.kde.org/stable5/en/pim/kmail2/configure-appearance.html#configure-appearance-systemtray says If you enable the system tray icon then a small KMail icon with the number of unread messages will be shown in the system tray. You can enable KMail's system tray icon with Enable system tray icon, and with System Tray Mode you can specify whether the tray icon should always be shown or only if you have unread messages. If the icon is visible then you can hide KMail's main window by clicking on the icon or by clicking on the window close button. By clicking on the icon you can make KMail's main window visible again. If you click on the icon with the right mousebutton then you get a menu with a few useful commands. You can check for new mail, create a new message or quit KMail. Additionally, there is the entry New Messages In which lists all folders containing unread messages. If you choose one of those folders then this folder will be selected in KMail's main window.
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2019-05-08 03:50 +0200 |
| Message-ID | <xVjSx-2CL-1@gated-at.bofh.it> |
| In reply to | #208381 |
On Tuesday 07 May 2019 07:56:35 pm Dan Ritter wrote: > Gene Heskett wrote: > > 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. > > You're watching /var/mail/gheskett for new mail? > > Kmail can probably do that by itself. Yes it can pull from /var/mail/$name all by itself, but thats not in step with the incoming, and kmail freezes while its doing that, sometime for a minute+ at a time. This is essentially instant reaction to an incoming mail, with a kmail freeze in milliseconds. kmail is a single threaded program. > > https://docs.kde.org/stable5/en/pim/kmail2/configure-appearance.html#c >onfigure-appearance-systemtray > > says > > If you enable the system tray icon then a small KMail icon > with the number of unread messages will be shown in the system > tray. You can enable KMail's system tray icon with Enable system > tray icon, and with System Tray Mode you can specify whether the > tray icon should always be shown or only if you have unread > messages. > > If the icon is visible then you can hide KMail's main window by > clicking on the icon or by clicking on the window close button. > By clicking on the icon you can make KMail's main window visible > again. If you click on the icon with the right mousebutton then > you get a menu with a few useful commands. You can check for new > mail, create a new message or quit KMail. Additionally, there is > the entry New Messages In which lists all folders containing > unread messages. If you choose one of those folders then this > folder will be selected in KMail's main window. 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>
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2019-05-08 14:40 +0200 |
| Message-ID | <xVu1z-wY-7@gated-at.bofh.it> |
| In reply to | #208374 |
On Tue, May 07, 2019 at 11:23:46PM +0200, Esteban L wrote: > pid=$(pgrep -u $username nautilus) This may produce more than one value. > dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/$pid/environ | sed > 's/DBUS_SESSION_BUS_ADDRESS=//' ) This one tries to use the value of $pid but if that variable contains a space, tab or newline, the result of $pid is expanded unquoted, which results in more than one argument word. Let's say the output of your pgrep is two lines: 1700 25836 Your command gets expanded like this: dbus=$(grep -z DBUS_SESSION_BUS_ADDRESS /proc/1700 25836/environ | sed '...') So, grep is given the following argument words: <-z> <DBUS_SESSION_BUS_ADDRESS> </proc/1700> <25836/environ> The -z is an option with no argument. So the word after that is the pattern to be searched for. And the two words after that are the files that grep will try to open. Therefore, grep tries to open the file /proc/1700 and the file 25836/environ to read them and search for your pattern. The result is > grep: /proc/1700: Is a directory > grep: 25836/environ: No such file or directory The script you've got is not designed to handle the case where pgrep finds more than one process and reports more than one PID. It has to be rewritten to handle that.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2019-05-08 18:40 +0200 |
| Message-ID | <xVxLQ-2Ry-13@gated-at.bofh.it> |
| In reply to | #208395 |
On Wed 08 May 2019 at 08:33:05 (-0400), Greg Wooledge wrote: > On Tue, May 07, 2019 at 11:23:46PM +0200, Esteban L wrote: > > pid=$(pgrep -u $username nautilus) > > This may produce more than one value. > The script you've got is not designed to handle the case where pgrep finds > more than one process and reports more than one PID. It has to be > rewritten to handle that. … and for none. What's nautilus? :) Cheers, David.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web