(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.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
