Re: .bash_profile: line execution based on su vs. direct login. [SOLVED]

2019-11-22 Thread Tim via users
On Fri, 2019-11-22 at 02:45 +, 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,

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread Todd Zullinger
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 runni

Re: .bash_profile: line execution based on su vs. direct login. [SOLVED]

2019-11-21 Thread home user
> 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

Re: .bash_profile: line execution based on su vs. direct login. [SOLVED]

2019-11-21 Thread Samuel Sieb
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.

Re: .bash_profile: line execution based on su vs. direct login. [SOLVED]

2019-11-21 Thread home user
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.

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread home user
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.

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread Samuel Sieb
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

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread Todd Zullinger
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 f

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread Samuel Sieb
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. ___ users mailing list -- users@lists.fedoraproject

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread home user
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/b

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-21 Thread Patrick O'Callaghan
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

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Ed Greshko
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" ]] ; 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:

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Todd Zullinger
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 ksysguar

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread home user
> 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 s

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Ed Greshko
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

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Ed Greshko
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 optio

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread home user
> 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 user

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread home user
> 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_profil

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Ed Greshko
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 manag

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread home user
> 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

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-20 Thread Patrick O'Callaghan
On Tue, 2019-11-19 at 20:55 -0700, home user wrote: > if ! [[ "ps -ef | grep [k]sysguard" ]] ; then > ksysguard & > fi > - if ! pidof ksysguard > /dev/null ; then ... fi poc ___ users mailing list -- users@lists.fedoraproject.org To un

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread Todd Zullinger
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

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread Ed Greshko
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 th

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread home user
(responding to three posts) (Garry) > This may help: > https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is... Thank-you, Garry.  I read it.  I don't see how that helps.  Her

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread Ed Greshko
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:

Re: .bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread Garry Williams
This may help: https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is-login-interactive-batch On Tue, Nov 19, 2019 at 11:14 AM home user wrote: > > (Fedora-30) > > good morning, > > My .bash_profile looks like this: > --- > # .bash_profile > > # Get the aliases and

.bash_profile: line execution based on su vs. direct login.

2019-11-19 Thread home user
(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. -