On 6/2/23 04:56, lejeczek via users wrote:
Hi guys
I have one specific user whose PS1 if not set in .bash_profile, is taken
from somewhere else.
At the same time globally I set PS1 in /etc/environment - bu that, this
one user does not honor.
I've tried a few terminal/console apps
On 02/06/2023 13:56, lejeczek via users wrote:
Hi guys
I have one specific user whose PS1 if not set in
.bash_profile, is taken from somewhere else.
At the same time globally I set PS1 in /etc/environment -
bu that, this one user does not honor.
I've tried a few terminal/console apps
On Fri, Jun 2, 2023 at 7:56 AM lejeczek via users
wrote:
>
> I have one specific user whose PS1 if not set in .bash_profile, is taken from
> somewhere else.
> At the same time globally I set PS1 in /etc/environment - bu that, this one
> user does not honor.
> I've tried
Hi guys
I have one specific user whose PS1 if not set in
.bash_profile, is taken from somewhere else.
At the same time globally I set PS1 in /etc/environment - bu
that, this one user does not honor.
I've tried a few terminal/console apps - no difference.
Where else can PS1 be set and/o
On 12Jan2022 18:35, Stephen J. Turnbull wrote:
>Running a new shell under the old one is always safe (since the old
>shell is still there when you exit this one), and if you need "login"
>behavior, "bash -l" gives you that.
+100 for this. Ashamed that I forgot to suggest it. Thanks, Cameron
_
> Or you can source your .profile (or separate script):
>
> . ~/.bash_profile
Be very careful with sourcing. These scripts are likely to set things
in your environment or start processes that are appropriate at
initialization, but will trash your current environment. For example,
typi
process of the GUI, and not a login shell, it
never ran .bash_profile.
This has been a pain for me because I’m used to variables being set in the
login PAM stack, such as the randomized named Kerberos CCache being available
to the GUI. Whoops, can’t read my kerberized NFS homedir! Can’t use Ker
nsole. According to its settings, it runs /bin/bash when it starts up.
If that setting is a command string, try changing it to:
/bin/bash --login
>OK, so there is my issue. ~/ does not have a .bashrc. I has
>.bash_profile only.
I would put env settings in .bash_profile myself.
>&g
On Tue, 11 Jan 2022 at 17:15, linux guy wrote:
> I'm trying to add a few directories to PATH in F35. I'm embarrassed to
> admit it isn't going well.
>
Don't be embarrassed, Managing the PATH has problematic since UNIX was a
teenager, as evidenced
by the date in the following publication (allowi
>
> >Where is PATH stored in F35 ?
>
> In your processes' memory. Unhelpful. But it is _initialised_ by your
> login sequence. Yes, being pedantic here.
>
Ha.
> >When exactly does .bash_profile get executed ?
>
> 1: Is your shell bash? (My interactive shell
On 12/01/2022 05:15, linux guy wrote:
I'm trying to add a few directories to PATH in F35. I'm embarrassed to admit
it isn't going well.
Where is PATH stored in F35 ?
When exactly does .bash_profile get executed ?
How does one get the bash environment reloaded without logging
Yes, being pedantic here.
>When exactly does .bash_profile get executed ?
1: Is your shell bash? (My interactive shell is zsh, by contrast.)
Echoing $SHELL should confirm bash for you, or looking in /etc/passwd.
2: .bash_profile (or .profile, if the former is missing) gets run by
_login_ shells
I'm trying to add a few directories to PATH in F35. I'm embarrassed to
admit it isn't going well.
Where is PATH stored in F35 ?
When exactly does .bash_profile get executed ?
How does one get the bash environment reloaded without logging out and
logging in ? $source ? $exec
40dd2e1e]
> custom-command=''
> login-shell=false
> use-custom-command=false
> visible-name='My Profile'
>
> However, this is not a bash issue, but a gnome-terminal
>
> Actually, I probably made a mistake before.
> Checking "run command as a login shell
this is not a bash issue, but a gnome-terminal
Actually, I probably made a mistake before.
Checking "run command as a login shell" in the right profile, I get .bash_profile sourced.
Now
.bashrc and .bash_profile
are sourced.
Sent: Thursday, June 25, 2020 at 8:03 P
On Thu, 25 Jun 2020 at 14:15, Patrick Dupre wrote:
> Thanks for the advises.
>
> In one case I get from ps -f (when .bash_profile is sourced
> pdupre 427492634 0 18:47 pts/500:00:00 -bash
> and in the other case
> pdupre 407492634 0 18:47 pts/500
Thanks for the advises.
In one case I get from ps -f (when .bash_profile is sourced
pdupre 42749 2634 0 18:47 pts/5 00:00:00 -bash
and in the other case
pdupre 40749 2634 0 18:47 pts/5 00:00:00 bash
In both cases echo $-
provides
himBHs
In both cases
/etc
Are you using some form of remote access for one of the machines?
> *Sent:* Thursday, June 25, 2020 at 5:55 PM
> *From:* "Qiyu Yan"
> *To:* "Community support for Fedora users"
> *Subject:* Re: .bash_profile
> Patrick Dupre 于 2020年6月25日周四 下午10:40写道：
>
In both cases,
"Run commad as a login shell" is checked.
Sent: Thursday, June 25, 2020 at 5:55 PM
From: "Qiyu Yan"
To: "Community support for Fedora users"
Subject: Re: .bash_profile
Patrick Dupre <pdu...@gmx.com> 于 2020年6月25日周四 下午10:40写
man bash and search bash_profile it details when it gets called or not.
The short details are there are interactive shells, login shells, and
non-interactive shells and each have slightly different rules for what
gets sourced.
On Thu, Jun 25, 2020 at 9:40 AM Patrick Dupre wrote:
>
>
Patrick Dupre 于 2020年6月25日周四 下午10:40写道：
> Hello,
>
> What control the call to .bash_profile?
> I am 2 machines and a different behavior while, I cannot see the
> difference in the configuration.
>
Whether the shell is a "login shell", a login shell will source
.ba
Hello,
What control the call to .bash_profile?
I am 2 machines and a different behavior while, I cannot see the
difference in the configuration.
On both machines .bash_profile is run in text terminal
But on one, it is also run in gnome-terminal
but not on the other one.
I check the profile
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,
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
> 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
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.
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
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 alwa
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
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
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
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/.
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
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:
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
> 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.
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
expende
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
> 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
ary 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
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 rea
> 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
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
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
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
ee 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 te
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 envir
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_profi
(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
Hello!
Running Fedora fc12. There seems to be a problem with the mdadm
package. The mdmonitor deamon is started as user root, and the problem
is that the file ~/.bash_profile is executed during startup of
/etc/init.d/mdmonitor. The line in this script that starts mdadm, is:
daemon --user=root
Ed Greshko wrote:
> Sam Sharpe wrote:
>
>>
>> What about this then?
>>
>> [...@samlap ~]$ echo $PATH
>> /usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/real/RealPlayer:/home/sam/.bin:/opt/real/RealPlayer:/home/sam/.bin
On Thu, 4 Feb 2010 17:08:56 -0800
suvayu ali wrote:
> That Bugzilla says updates have been pushed to F10. Shouldn't that
> mean its fixed in F11 and F12?
That bugzilla just complained that sudo -V printed info
that conflicted with the behavior of sudo. Apparently the update
they pushed merely mad
;>> Are you sure? I tried this after your post on my lab machine (not
>>> Fedora though, its Ubuntu 9.04)
>>>
>>> $ sudo echo $PATH
>>> [sudo] password for suvayu:
>>> /home/suvayu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/g
ld it from source. It
>>> has been like this for a while now.
>>>
>>
>> Are you sure? I tried this after your post on my lab machine (not
>> Fedora though, its Ubuntu 9.04)
>>
>> $ sudo echo $PATH
>> [sudo] password for suvayu:
>> /home/s
ld it from source. It
>>> has been like this for a while now.
>>>
>>
>> Are you sure? I tried this after your post on my lab machine (not
>> Fedora though, its Ubuntu 9.04)
>>
>> $ sudo echo $PATH
>> [sudo] password for suvayu:
>> /home/s
>
> Are you sure? I tried this after your post on my lab machine (not
> Fedora though, its Ubuntu 9.04)
>
> $ sudo echo $PATH
> [sudo] password for suvayu:
> /home/suvayu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/suvayu/root/bin
>
>
$PATH
[sudo] password for suvayu:
/home/suvayu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/suvayu/root/bin
I see two different directories that I add to $PATH in my
.bash_profile and .bashrc
> https://bugzilla.redhat.com/show_bug.cgi?id=475990
>
>
On Thu, 4 Feb 2010 16:00:39 -0800
suvayu ali wrote:
> As far as I understand this, sudo still uses your (the regular user's)
> $PATH.
Nope, that's merely what the docs claim. In fact, the security geeks
decided sudo absolutely needed to have a hard coded PATH and as far
as I know the only way to
ried to add the /sbin and /usr/sbin PATH in .bash_profile but I still have
> the same problem.
>
> If I use the command su, and if I run the command echo $PATH, the /sbin and
> the /usr/sbin is there.
> /usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:
Hello,
I have a problem with my fedora 12 box. There is no /sbin and /usr/sbin PATH
after using sudo. This is the output if I run the command echo $PATH.
/usr/kerberos/sbin:/usr/kerberos/bin:/usr/bin:/bin
I tried to add the /sbin and /usr/sbin PATH in .bash_profile but I still have
the same
60 matches
Mail list logo
