(Fedora-30)
good morning,
My .bash_profile looks like this: --------------- # .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
ksysguard &
# the end. --------------- But I want the KSysGuard to be launched only when: * the session is interactive (not batch, cron, anacron, or at); and * it's a direct login from the login screen, not an "su" connection. How do I do that in my .bash_profile? That is, ----- if [ what goes here? ]; then ksysguard & fi ----- How do I, within the .bash_profile if test, distinguish su connection vs. direct login from the login screen?
Bill.
This may help: https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is-lo...
On Tue, Nov 19, 2019 at 11:14 AM home user mattisonw@comcast.net wrote:
(Fedora-30)
good morning,
My .bash_profile looks like this:
# .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
ksysguard &
# the end.
But I want the KSysGuard to be launched only when:
- the session is interactive (not batch, cron, anacron, or at);
and
- it's a direct login from the login screen, not an "su" connection.
How do I do that in my .bash_profile? That is,
if [ what goes here? ]; then ksysguard & fi
How do I, within the .bash_profile if test, distinguish su connection vs. direct login from the login screen?
Bill. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 11/20/19 12:13 AM, home user wrote:
(Fedora-30)
good morning,
My .bash_profile looks like this:
# .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
ksysguard &
# the end.
But I want the KSysGuard to be launched only when:
- the session is interactive (not batch, cron, anacron, or at);
and
- it's a direct login from the login screen, not an "su" connection.
How do I do that in my .bash_profile? That is,
if [ what goes here? ]; then ksysguard & fi
How do I, within the .bash_profile if test, distinguish su connection vs. direct login from the login screen?
Are you a KDE user? If so, and you want ksysguard started when you login to a KDE session why not use System Settings-->Workspace--->Startup & Shutdown--->Autostart?
(responding to three posts)
(Garry)
This may help:
https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is... https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is-login-interactive-batch Thank-you, Garry. I read it. I don't see how that helps. Here's the scenario: ----- [part 1] user1 powers up the workstation; it boots up fine; the login screen is displayed. user1 logs in as user1; user1's .bash_profile launches ksysguard. (it's interactive mode now, right?) user1 launches a terminal. [part 2] in the terminal, user1 enters the command "su --login user2". su prompts for user2's password; he enters it. (it's interactive mode now, right?) ----- Now it's unlikely that user2 wants a new ksysguard launched by his .bash_profile at this point, since the ksysguard launched by user1's .bash_profile is still running.
But if after power-up and boot-up, the user logs in as user2, there is not a ksysguard already running. Yet he's in interactive mode. So his .bash_profile should launch ksysguard.
My sense is that testing for interactive mode won't work here. I've also looked at info on bash (before opening this thread). My sense is that some su vs. direct login indicator that can be tested inside a bash script does not exist. (If I'm wrong, I'd like to know!) Now I'm looking for a different kind of solution.
(Ed)
Are you a KDE user?
Thank-you, Ed. Well, after 6 years, you haven't made me a KDE convert yet! :) I'm mostly a Gnome user.
If so, and you want ksysguard started when you login to a KDE session why not use System Settings-->Workspace--->Startup &
Shutdown--->Autostart? I put ksysguard in between the "then" and the "fi" hoping that making this simple and concrete would help this thread go quick and easy. The real .bash_profile has stuff there that's more complicated and less well known.
(me) After coming to think that login and interactive modes are not the answer, I started digging into ps, and piping its output into grep. Unfortunately, that generates another process "grep ksysguard ...". Piping into "grep -v ..." also doesn't help. After groping all over grep and bash today and trying lots of things, I got lucky. In the GNU Grep 3.3 web page "http://www.gnu.org/software/grep/manual/grep.html", I found this: ----- 7. Why do people use strange regular expressions on |ps| output?
ps -ef | grep '[c]ron'
If the pattern had been written without the square brackets, it would have matched not only the |ps| output line for |cron|, but also the |ps| output line for |grep|. Note that on some platforms, |ps| limits the output to the width of the screen; |grep| does not have any limit on the length of a line except the available memory. ----- So user2's .bash_profile if block should look like this: ----- if ! [[ "ps -ef | grep [k]sysguard" ]] ; then ksysguard & fi ----- I tried it. It works, both with direct login (ksysguard is launched) and su (a second ksysguard is not launched).
The main problem is solved. But this leaves me with two follow-up questions: 1. How does the [first_letter] prevent matching the ps output line for grep? (I'm almost certain I'm not the only member of this list not knowing the answer to this!) It works, and I'm using it, but it would be good to really understand how it works (beyond what the GNU grep page says). I saw no hint of an answer in the regular expression write-up. 2. Is there a way to have a *single* grep match one string and not another. Example: find all lines containing "ksysguard" but not "grep". Note that grep ksysguard | grep -v grep is *not* what I'm looking for.
thanks, Bill.
On 11/20/19 11:55 AM, home user wrote:
FWIW, it is bad practice to answer multiple posts in the same message.
Anyway....
Are you a KDE user?
Thank-you, Ed. Well, after 6 years, you haven't made me a KDE convert yet! :) I'm mostly a Gnome user.
For GNOME it is almost as simple.
If the directory doesn't already exist....
mkdir ~/.config/autostart
Then create a file called something like ksysguard.desktop in that directory with the following contents.
[Desktop Entry] Version=1.0 Name=Ksysguard GenericName=Watch Exec=ksysguard Terminal=false Type=Application
And you're done.
ksysguard will start the next time you login.
home user wrote:
After coming to think that login and interactive modes are not the answer, I started digging into ps, and piping its output into grep. Unfortunately, that generates another process "grep ksysguard ...". Piping into "grep -v ..." also doesn't help. After groping all over grep and bash today and trying lots of things, I got lucky. In the GNU Grep 3.3 web page "http://www.gnu.org/software/grep/manual/grep.html", I found this:
- Why do people use strange regular expressions on |ps| output?
ps -ef | grep '[c]ron'
You could also use 'pgrep ksysguard' instead of piping ps to grep. That avoids both a pipe and the need to hide the grep command from the grep.
The main problem is solved. But this leaves me with two follow-up questions:
- How does the [first_letter] prevent matching the ps output line for
grep? (I'm almost certain I'm not the only member of this list not knowing the answer to this!) It works, and I'm using it, but it would be good to really understand how it works (beyond what the GNU grep page says). I saw no hint of an answer in the regular expression write-up.
When you run ps -ef | grep ksysguard, the ps list includes entries for both ps -ef and grep ksysguard. Adding the bracets around a character in the grep command means that the grep pattern is looking for that one character followed by the others, in the case of 'grep [k]sysguard' the regular expression is k followed by sysguard.
In the ps -ef output, the string [k]sysguard doesn't match because there are literal brackets there. In the grep regex, those brackets have special meaning. So this is a good method for filtering such matches in the output of ps.
But pgrep is generally easier and purpose-built for that particular problem.
- Is there a way to have a *single* grep match one string and not another.
Example: find all lines containing "ksysguard" but not "grep". Note that grep ksysguard | grep -v grep is *not* what I'm looking for.
Yes, by ensuring the regex is precise and doesn't match both lines, which is just what using [k]sysguard does. You might be able to do this with something fancy like a negative lookbehind, using 'grep -P' but I'm not sure.
Or you could use a regex which took advantage of the ps -ef output format, like ps -ef | grep '[0-9] ksysguard'. That won't match the grep for ksysguard because it's only looking for a number followed by a space, followed by ksysguard.
Both are far less elegant/readable than grep [k]sysguard. :) Which is itself less elegant than using pgrep. And in this case, I think, pgrep is far less elegant than using the desktop's autostart functions, as Ed showed for both Gnome and KDE.
FWIW, it is bad practice to answer multiple posts in the same message.
I didn't know that. sorry.
For GNOME it is almost as simple. ...
Thank-you, Ed. I'm using ksysguard in this thread for simplicity. My real .bash_profile is trying to manage two pairs of xeyes, each with 5 command line options.
Bill.
On 11/21/19 7:29 AM, home user wrote:
FWIW, it is bad practice to answer multiple posts in the same message.
I didn't know that. sorry.
For GNOME it is almost as simple. ...
Thank-you, Ed. I'm using ksysguard in this thread for simplicity. My real .bash_profile is trying to manage two pairs of xeyes, each with 5 command line options.
Are you saying that the question you asked initially isn't the actual one you needed answering?
You could also use 'pgrep ksysguard' ...
Thank-you, Todd. I tried it. It does not work. I don't know why. When I log in as user1, and then do "su --login user2", it does work. When I log in as user2, it does not work. I did a lot of testing using ordinary bash scripts rather than .bash_profile. I get the same results. I tried both if ! [[ "pgrep ksysguard" ]] ; then and if [[ "pgrep -v ksysguard" ]] ; then No difference. I tried both single quotes and double quotes; no difference. I tried these with user2 being a regular user and with user2 being root; no difference.
So I'm back to if ! [[ "ps -ef | grep [k]sysguard" ]] ; then
Thank-you for your answers to my follow-up questions.
I'm using ksysguard in this thread for simplicity. My real .bash_profile is trying to manage two pairs of xeyes, each with 5 command line options. So Ed's autostart suggestions do not apply.
Bill.
if ! pidof ksysguard > /dev/null ; then ...
Thank-you Patrick. I studied the man page for pidof. As I understand it, it implies that pidof does not work across login names; user2 cannot see user1's processes: ----- [from the description of option "-c"] This option is ignored for non-root users, as they will be unable to check the current root directory of processes they do not own. ----- So this will not work.
Bill.
On 11/21/19 7:52 AM, home user wrote:
if ! pidof ksysguard > /dev/null ; then ...
Thank-you Patrick. I studied the man page for pidof. As I understand it, it implies that pidof does not work across login names; user2 cannot see user1's processes:
[from the description of option "-c"] This option is ignored for non-root users, as they will be unable to check the current root directory of processes they do not own.
So this will not work.
[egreshko@meimei ~]$ whoami egreshko
[egreshko@meimei ~]$ pidof kwrite 22679
[egreshko@meimei ~]$ ps -eaf | grep 22679 maria 22679 22630 0 07:55 pts/1 00:00:00 kwrite
You misunderstand the meaning of -c. It has to do with the directory when the command was started. In order to determine that, a process must be able to known what /proc/$PID/cwd is.
For a "maria" process
[egreshko@meimei 22679]$ pwd /proc/22679
[egreshko@meimei 22679]$ ll cwd ls: cannot read symbolic link 'cwd': Permission denied lrwxrwxrwx. 1 maria maria 0 Nov 21 07:55 cwd
Conversely, for one of "egreshko" processes....
[egreshko@meimei 22833]$ pwd /proc/22833 [egreshko@meimei 22833]$ ll cwd lrwxrwxrwx. 1 egreshko egreshko 0 Nov 21 08:01 cwd -> /home/egreshko
On 11/21/19 7:43 AM, home user wrote:
My real .bash_profile is trying to manage two pairs of xeyes, each with 5 command line options. So Ed's autostart suggestions do not apply.
Why don't you state precisely what you'd like to accomplish so energy isn't expended by folks on issues which may not be related to what you actually need to determine.
Are you saying that the question you asked initially isn't the actual one you needed answering?
The initial question was:
How do I, within the .bash_profile if test, distinguish su connection vs. direct login from the login screen?
That was the real question. I needed that answered so I could manage the launching of two pairs of xeyes, each with several options. But that's messy. So to make the discussion easier, I substituted a simpler scenario by framing it as wanting to manage the launching of one ksysguard (no options). It shouldn't matter what the if block is meant to control. I'm trying to help everyone help me by simplifying the scenario.I hope that that's not a problem.
So the answer to your question is both "yes" and "no", but the "yes" part was to make things easier for everyone.
Bill.
home user wrote:
You could also use 'pgrep ksysguard' ...
Thank-you, Todd. I tried it. It does not work. I don't know why.
Nor do I. We'd need to see the actual code you ran and its output for that. :)
I tried both if ! [[ "pgrep ksysguard" ]] ; then and if [[ "pgrep -v ksysguard" ]] ; then No difference. I tried both single quotes and double quotes; no difference. I tried these with user2 being a regular user and with user2 being root; no difference.
Those aren't actual code snippets you used, are they? This code:
if ! [[ "pgrep ksysguard" ]] ; then
is testing whether the string is empty or not rather than running the command and checking for output. You can see that by running:
$ [[ "anything" ]] && echo pass || echo fail pass
or
$ [[ "" ]] && echo pass || echo fail fail
You more likely want something like:
if pgrep ksysguard >/dev/null; then ... fi
I'm using ksysguard in this thread for simplicity. My real .bash_profile is trying to manage two pairs of xeyes, each with 5 command line options. So Ed's autostart suggestions do not apply.
Echoing what Ed said in another reply, I think you'd be more likely to get decent answers if you posted some actual code and the output.
If you strip the code down for the example you need to be sure that it properly demonstrates the problem you're trying to solve.
Otherwise the folks here might post prefectly fine ways to solve the problem you've given but not the one you actually have.
On 11/21/19 2:30 PM, Todd Zullinger wrote:
Those aren't actual code snippets you used, are they? This code:
if ! [[ "pgrep ksysguard" ]] ; thenis testing whether the string is empty or not rather than running the command and checking for output. You can see that by running:
Maybe the OP meant to type
if ! [[ `pgrep ksysguard` ]]
??
:-)
On Wed, 2019-11-20 at 16:52 -0700, home user wrote:
if ! pidof ksysguard > /dev/null ; then ...
Thank-you Patrick. I studied the man page for pidof. As I understand it, it implies that pidof does not work across login names; user2 cannot see user1's processes:
You misread what the man page says.
[from the description of option "-c"] This option is ignored for non-root users, as they will be unable to check the current root directory of processes they do not own.
Irrelevant. Your use case does not require the '-c' flag. Neither does my example.
So this will not work.
Yes it will.
Also, could you please configure your mail client to do proper reply quoting with attribution? See virtually every other message reply on this list for examples.
poc
I think at this point I should sort-of start over.
Here is user1's actual .bash_profile: -----bash.1[~]: cat .bash_profile # .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
# put one pair of xeyes in the upper right corner of the left monitor, # and one pair of xeyes in the upper left corner of the right monitor. /usr/bin/xeyes -geometry 1000x150+1559+0 -fg black -center pink -outline black & /usr/bin/xeyes -geometry 1000x150+2560+0 -fg white -center black -outline red &
# the end. bash.2[~]: -----
Here is user2's actual .bash_profile: ----- -bash.1[~]: cat .bash_profile # .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
# put one pair of xeyes in the upper right corner of the left monitor, # and one pair of xeyes in the upper left corner of the right monitor. /usr/bin/xeyes -geometry 300x300+2259+0 -fg black -center pink -outline black & /usr/bin/xeyes -geometry 300x300+2560+0 -fg white -center black -outline red &
# the end. -bash.2[~]: ----- (yes, the xeyes options are different from those of user1)
A. When, from the login screen, I log in as user1, the xeyes show up as they should. B. When, from the login screen, I log in as user2, the xeyes show up as they should. C. (3 steps) 1. From the login screen, I log in as user1; the xeyes show up as they should. 2. I launch a terminal. 3. In that user1 terminal, I enter "su --login user2", and then enter the password. xeyes show up the same as in B above. That happens to be directly on top of the xeyes launched in step 1.
I do not want any change in A and B; they should continue just as they are. But I want C.3 to *not* launch new xeyes at all, since the xeyes launched in step 1 are still there and functioning as they should.
I'm trying to achieve this in the .bash_profile scripts by putting the launches of the xeyes in a bash if-block. Example... ----- if ! [[ "pgrep xeyes > /dev/null" ]] ; then xeyes [etc] xeyes [etc] fi ----- But so far, everything I've tried for the test in the if line has failed. What should I put in the if line's [[ ]]? While waiting for replies, I'll start experimenting with "pidof" as suggested by Patrick and Ed, and what Todd suggested in his most recent post.
side comment/request: Last month, I changed the e-mail address associated with my Fedora users list account from a yahoo address to a comcast address. For this post, I used HYPERKITTY to reply to my original post. If this shows up in HYPERKITTY but *not* in your e-mail, please let the list know.
Samuel Sieb wrote:
On 11/21/19 1:16 PM, home user wrote:
if ! [[ "pgrep xeyes > /dev/null" ]] ; then
This is still the problem. Remove those quotes. And you could remove the brackets as well, they aren't necessary.
Indeed. And while pidof would have probably been a better solution for the initial problem we thought we were trying to solve, I think knowing that you only want to skip user1 from starting new xeyes if it is already running for user1 that pgrep will be better suited. With pgrep you can use the -u/--euid or -U/--uid option to limit the match to xeyes processes which are running for the proper user.
Something like:
if ! pgrep -u user1 xeyes > /dev/null; then xeyes ... fi
On 11/21/19 1:48 PM, Todd Zullinger wrote:
Samuel Sieb wrote:
On 11/21/19 1:16 PM, home user wrote:
if ! [[ "pgrep xeyes > /dev/null" ]] ; then
This is still the problem. Remove those quotes. And you could remove the brackets as well, they aren't necessary.
Indeed. And while pidof would have probably been a better solution for the initial problem we thought we were trying to solve, I think knowing that you only want to skip user1 from starting new xeyes if it is already running for user1 that pgrep will be better suited. With pgrep you can use the -u/--euid or -U/--uid option to limit the match to xeyes processes which are running for the proper user.
I don't think that would work in this case. The problem is that he's switching users, so from one user account he would need to check for the processes under the other user, not the current one. Assuming that he's only going to have one user logged in to the desktop at a time, this is the best option. Although "pidof" should work equally well.
Thank-you, Samuel.
I did the experiment. Both the double-quotes and the square brackets had to be deleted. The result worked for user1 and user2 being regular users. Next I'll edit root's .bash_profile, and see if the solution works when user2 is root. Actually, user2 almost always is root.
Bill.
and the answer is... ----- bash.1[~]: cat .bash_profile # .bash_profile
# Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH
# If there are no xeyes already running, then... if ! pgrep xeyes > /dev/null ; then # put one pair of xeyes in the upper right corner of the left monitor... /usr/bin/xeyes -geometry 1000x150+1559+0 -fg black -center pink \ -outline black & # and one pair of xeyes in the upper left corner of the right monitor. /usr/bin/xeyes -geometry 1000x150+2560+0 -fg white -center black \ -outline red & fi
# the end. bash.2[~]: ----- ... and that's my final answer (I hope!). It works whether both users are regular users or one user is root.
(regarding Patrick's, Ed's, Todd's, and Samuel's "pidof" suggestion) I tried that too, after getting the above script done and tested. It does work. I did mis-understand the -c option. But I think the main problem was I was using the quotes and square brackets in the if line.
(Ed's question about mis-typing the single quote) I used the key between the semi-colon key and the "enter" key, not the key above the "tab" key. (Now I know that both were wrong!)
Apart from binders, functors, and functional programming, I'm an excellent C++ programmer. But I've done hardly any shell script programming. I did not know the meaning and use of the double quotes and the square brackets in the if line. This is what caused me so much trouble in my experimenting.
I'm tagging this thread SOLVED. I thank everyone who tried to help. Bill.
On 11/21/19 4:24 PM, home user wrote:
# put one pair of xeyes in the upper right corner of the left monitor... /usr/bin/xeyes -geometry 1000x150+1559+0 -fg black -center pink \ -outline black & # and one pair of xeyes in the upper left corner of the right monitor. /usr/bin/xeyes -geometry 1000x150+2560+0 -fg white -center black \ -outline red &
Just for curiosity, why? Is it so you can find your mouse pointer?
On 11/21/19 4:24 PM, home user wrote:
Just for curiosity, why? Is it so you can find your mouse pointer?
Yes. In the good 'ol days when I was an AWIPS programmer, I learned the advantage of a 2-monitor workstation. At least a decade ago, published human factors research confirmed that a 2-monitor system improves productivity about 40%. But it's easy to lose the cursor when there's so much display real-estate. It's been my experience for years that xeyes really helps find and keep track of the trackball pointer's location.
I've also seen other people get a kick out of the xeyes when they see them on my monitors.
If you have enough space on your screen, give it a try!
I wish xsnow would work on my workstation, but it doesn't. No real practical value, but a neat novelty.
Bill.
Samuel Sieb wrote:
On 11/21/19 1:48 PM, Todd Zullinger wrote:
Indeed. And while pidof would have probably been a better solution for the initial problem we thought we were trying to solve, I think knowing that you only want to skip user1 from starting new xeyes if it is already running for user1 that pgrep will be better suited. With pgrep you can use the -u/--euid or -U/--uid option to limit the match to xeyes processes which are running for the proper user.
I don't think that would work in this case. The problem is that he's switching users, so from one user account he would need to check for the processes under the other user, not the current one. Assuming that he's only going to have one user logged in to the desktop at a time, this is the best option. Although "pidof" should work equally well.
If you're running as user1 and want to ensure that only one copy of xeyes is running as user1, you can use
pgrep -U user1 xeyes (or pgrep -U $(id -un) xeyes)
to check. Or you could run
pgrep -U user2 xeyes
if you wanted to check for the other user. Either way, that does help with what I understood to be the problem here. I'm sure there are many ways to solve it, but I don't think pidof works as far as I understood things.
Whether that's actually useful in this problem is hard to say for sure. But those options are useful if you're testing whether a program is running and need to distinguish if it's running at all versus running as a particular user.
On Fri, 2019-11-22 at 02:45 +0000, home user wrote:
it's easy to lose the cursor when there's so much display real- estate. It's been my experience for years that xeyes really helps find and keep track of the trackball pointer's location.
It doesn't help when things blank the mouse cursor, either. When VLC is playing a video file it'll blank the cursor, and the cursor can stay blanked even when you move it away from the video playback area. Sometimes you have to madly mouse all over the table trying to get the mouse cursor to re-appear.
I think I'll set up xeyes, too.
-
Ed Greshko -
Garry Williams -
home user -
Patrick O'Callaghan -
Samuel Sieb -
Tim -
Todd Zullinger