(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.