Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/11/17 2:58 PM, Greg Wooledge wrote: > If the goal is ONLY to configure the environment that appears within > an interactive shell, then you can short circuit the DM/DE/WM > configuration steps and simply tell the terminal emulator to run > login shells instead of regular shells. Yes, I'm

Re: ~/.profile and ~/.bash_profile aren't executed on login

On Mon, Dec 11, 2017 at 01:57:52PM -0500, Chet Ramey wrote: > On 12/11/17 1:30 PM, Yuri wrote: > > /usr/local/bin/bash is set as user's login shell in 'vipw'. So when this > > user logs in, it must be invoked as a login shell. Is this correct? > > Nobody on the list can answer that question. It

Re: ~/.profile and ~/.bash_profile aren't executed on login

On Mon, Dec 11, 2017 at 10:30:51AM -0800, Yuri wrote: > On 12/11/17 06:03, Chet Ramey wrote: > /usr/local/bin/bash is set as user's login shell in 'vipw'. So when this > user logs in, it must be invoked as a login shell. Is this correct? No. Because you are logging in with a Display Manager, not

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/11/17 06:03, Chet Ramey wrote: Bash, as documented, reads ~/.bash_profile first when it's invoked as a login shell, falling back to ~/.bash_login and ~/.profile if it's not there. I just verified: none of these 3 files are executed by bash when user logs in. /usr/local/bin/bash

Re: ~/.profile and ~/.bash_profile aren't executed on login

'echo "==> executing ~/.profile"' > ~/.profile > ln -s /usr/local/bin/bash /usr/local/bin/sh > /usr/local/bin/sh --login > ==> executing ~/.profile > /usr/local/bin/bash --login > > > It only calls ~/.profile when it is named 'sh'. OK, this is progress. Bas

Re: ~/.profile and ~/.bash_profile aren't executed on login

On Sun, Dec 10, 2017 at 07:22:36PM -0800, Yuri wrote: > It only calls ~/.profile when it is named 'sh'. In posix mode, bash only looks for ~/.profile, but when you run it in non-posix mode, it will look for ~/.bash_profile and ~/.bash_login first. You probably have a ~/.bash_profile in addit

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/10/17 13:51, Chet Ramey wrote: You have not described a bug, since you have not demonstrated that bash is behaving other than how it is documented, nor have you provided answers to any of the questions you've been asked. You haven't even determined whether or not bash is being invoked as a

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/10/17 3:18 PM, Yuri wrote: > On 12/09/17 14:14, Yuri wrote: >> None of these files are executed when bash is a user's default shell on >> FreeBSD. >> No special options were selected. Despite shell.c saying that they should >> be executed they just aren't. > > > The bug is that bash

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/09/17 14:14, Yuri wrote: None of these files are executed when bash is a user's default shell on FreeBSD. No special options were selected. Despite shell.c saying that they should be executed they just aren't. The bug is that bash doesn't handle login situation when it isn't linked to

Re: ~/.profile and ~/.bash_profile aren't executed on login

Yuri wrote: > Bob Proulx wrote: > > How is the user logging in? Are they logging in with 'ssh' over the > > network? Or are they logging in through an "xdm" X Display Manager > > login from a graphical login display? > > User logs in locally through the display manager. Which graphical display

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/9/17 6:41 PM, Yuri wrote: > On 12/09/17 15:24, Chet Ramey wrote: >> Of course not: that's not a login shell.  As the documentation says, >> >> "A login shell is one whose first character of argument zero is a -,  or >> one started with the --login option." >> >> The INVOCATION section of the

Re: ~/.profile and ~/.bash_profile aren't executed on login

On Sun, Dec 10, 2017 at 1:41 AM, Yuri wrote: > On 12/09/17 15:24, Chet Ramey wrote: > >> Of course not: that's not a login shell. As the documentation says, >> >> "A login shell is one whose first character of argument zero is a -, or >> one started with the --login option." >>

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/09/17 15:24, Chet Ramey wrote: Of course not: that's not a login shell. As the documentation says, "A login shell is one whose first character of argument zero is a -, or one started with the --login option." The INVOCATION section of the manual page explains it in exhaustive detail.

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/9/17 6:09 PM, Yuri wrote: > On 12/09/17 15:01, Chet Ramey wrote: >> Since it doesn't happen on any other OS, I suspect an issue with either the >> FreeBSD port or the pathname that appears in argv[0] when the shell is >> started, which is what bash uses to detect that it's been invoked as a

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/09/17 15:01, Chet Ramey wrote: Since it doesn't happen on any other OS, I suspect an issue with either the FreeBSD port or the pathname that appears in argv[0] when the shell is started, which is what bash uses to detect that it's been invoked as a login shell. The full path is

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/09/17 14:59, Bob Proulx wrote: How is the user logging in? Are they logging in with 'ssh' over the network? Or are they logging in through an "xdm" X Display Manager login from a graphical login display? User logs in locally through the display manager. Yuri

Re: ~/.profile and ~/.bash_profile aren't executed on login

On 12/9/17 5:14 PM, Yuri wrote: > None of these files are executed when bash is a user's default shell on > FreeBSD. > No special options were selected. Despite shell.c saying that they should > be executed they just aren't. > > Is this a bug? Since it doesn't happen on any other OS, I suspect

Re: ~/.profile and ~/.bash_profile aren't executed on login

Yuri wrote: > None of these files are executed when bash is a user's default shell on > FreeBSD. > No special options were selected. Despite shell.c saying that they should be > executed they just aren't. How is the user logging in? Are they logging in with 'ssh' over the network? Or are they

~/.profile and ~/.bash_profile aren't executed on login

None of these files are executed when bash is a user's default shell on FreeBSD. No special options were selected. Despite shell.c saying that they should be executed they just aren't. Is this a bug? Yuri

Re: bash version: 4.3.27(1) and .bashrc / .bash_profile

I don't know what version of bash you replaced, but it's likely that Red Hat defined that option before building the version of bash shipped with Fedora 6. It's been there for 15 years. Also must be present on much more recent Oracle Linux, and in fact I never found other behaviour.

Re: bash version: 4.3.27(1) and .bashrc / .bash_profile

commands as: su - [user] -c [command] neither .bashrc o .bash_profile on user home directory are executed. If I just execute su - [user] everything it's fine. I've changed the user shell on /etc/passwd to the previous ( original vulnerable) bash and my scripts are back to work

Re: bash version: 4.3.27(1) and .bashrc / .bash_profile

El sábado, 8 de noviembre de 2014 09:14:17 UTC+1, Piotr Grzybowski escribió: Hi, a bit strange. I do not think it is related to the patches. have added the path to your newly compiled and patched shell to /etc/shells? No, I didn't. In fact I just replaced the original bash with the

Re: bash version: 4.3.27(1) and .bashrc / .bash_profile

and compile it) Today I realized some processes were not working as expected. After some investigation I've realized that when executing commands as: su - [user] -c [command] neither .bashrc o .bash_profile on user home directory are executed. If I just execute su - [user] everything it's

Re: bash version: 4.3.27(1) and .bashrc / .bash_profile

El sábado, 8 de noviembre de 2014, Chet Ramey chet.ra...@case.edu escribió: This is controlled by the NON_INTERACTIVE_LOGIN_SHELLS option in config-top.h. It's not enabled by default. Define that option and rebuild, and you should have the behavior you want. Thank you, Thank you, Thank

bash version: 4.3.27(1) and .bashrc / .bash_profile

as expected. After some investigation I've realized that when executing commands as: su - [user] -c [command] neither .bashrc o .bash_profile on user home directory are executed. If I just execute su - [user] everything it's fine. I've changed the user shell on /etc/passwd to the previous

Re: ionice bash pid in bash_profile Fails

On Mon, Nov 22, 2010 at 08:39:49AM -0500, Greg Wooledge wrote: On Sun, Nov 21, 2010 at 04:08:33PM -0900, Roger wrote: When logging in, the following fails if put in $HOME/.bash_profile: ionice -c 2 -n 0 -p `pidof bash` ... I'm guessing, because bash hasn't started yet? I very much doubt

Re: ionice bash pid in bash_profile Fails

Roger wrote: If you want the PID of the current shell process, use $$ instead. Yes I do. It's only me on this computer, unless you're speculating on prioritizing a snooper. :-O This is (in this context) not related to the number pf bash processes running. Not at all. -- Be conservative

Re: ionice bash pid in bash_profile Fails

the error I get when logging into a virtual terminal and $HOME/.bash_profile executes or is read in: ionice: ioprio_set failed: No such process Perhaps pidof fails to find the -bash process due to the leading dash? Who knows? Who cares? Use $$ to get the PID of the shell. The following works

Re: ionice bash pid in bash_profile Fails

On Mon, Nov 22, 2010 at 12:44:54PM -0900, Roger wrote: ionice -c 2 -n 0 -p `echo $$` You don't need echo or `` here. ionice -c 2 -n 0 -p $$

Re: ionice bash pid in bash_profile Fails

process, use $$ instead. Here's the error I get when logging into a virtual terminal and $HOME/.bash_profile executes or is read in: ionice: ioprio_set failed: No such process Perhaps pidof fails to find the -bash process due to the leading dash? Who knows? Who cares? Use $$ to get the PID

ionice bash pid in bash_profile Fails

When logging in, the following fails if put in $HOME/.bash_profile: ionice -c 2 -n 0 -p `pidof bash` ... I'm guessing, because bash hasn't started yet? -- Roger http://rogerx.freeshell.org/

How to start bash without inheriting any environment variables and user level profiles (such as .bash_profile)?

I'm wondering how to start bash without inheriting any environment variables and user level profiles (such as .bash_profile). Would you please let me know what option to use? -- Regards, Peng

Re: How to start bash without inheriting any environment variables and user level profiles (such as .bash_profile)?

On Wed, Apr 28, 2010 at 02:38:01PM -0500, Peng Yu wrote: I'm wondering how to start bash without inheriting any environment variables and user level profiles (such as .bash_profile). Would you please let me know what option to use? env - $(command -v bash) --noprofile --norc You'd probably

Re: How to start bash without inheriting any environment variables and user level profiles (such as .bash_profile)?

Peng Yu wrote: I'm wondering how to start bash without inheriting any environment variables and user level profiles (such as .bash_profile). Would you please let me know what option to use? At login time only a bare minimum of environment variables exist. It is already almost a minimal set

Re: bash root ~/.bash_profile quirk

asherwolf [EMAIL PROTECTED] writes: When I use su to log into root, PATH is there, LD_RUN_PATH is there, and PKG_CONFIG_PATH is there, but not LD_LIBRARY_PATH (which makes some of my programs not cooperate) Is there something I'm missing? Why would an environment variable not show up? A

Re: bash root ~/.bash_profile quirk

Andreas Schwab wrote: A setuid binary ignores LD_LIBRARY_PATH for security reasons. Oh... I didn't know that, but now I do! Thanks! Asher -- View this message in context: http://www.nabble.com/bash-root-%7E-.bash_profile-quirk-tf4389588.html#a12533627 Sent from the Gnu - Bash

Re: bash root ~/.bash_profile quirk

On 2007-09-06, asherwolf wrote: I have the following in my root ~/.bash_profile: PATH=$PATH:$HOME/bin . PKG_CONFIG_PATH is there, but not LD_LIBRARY_PATH (which makes some of my programs not cooperate) Are you using su or su -? I'm using just su... should I use su - ? Asherwolf

Re: bash root ~/.bash_profile quirk

On 2007-09-06, asherwolf wrote: On 2007-09-06, asherwolf wrote: I have the following in my root ~/.bash_profile: PATH=$PATH:$HOME/bin . PKG_CONFIG_PATH is there, but not LD_LIBRARY_PATH (which makes some of my programs not cooperate) Are you using su or su -? I'm using just su

bash_profile ?

Are there any good bash_profile links, of showing how to create a good simple bash_profile, that would also include $PATH. Thanks - Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash

Re: ssh localhost date # no startup files read: ~/{.bash_profile, .bash_login, .profile, .bashrc}

Below are two tests cases for ssh localhost date. The Linux test shows that ~/.bashrc is read. The Cygwin case shows none of ~/{.bash_profile,.bash_login,.profile,.bashrc} are read. Doesn't this seem like a bug? There are two issues at play here. First, unless bash is compiled

ssh localhost date # no startup files read: ~/{.bash_profile,.bash_login,.profile,.bashrc}

vv Below are two tests cases for ssh localhost date. The Linux test shows that ~/.bashrc is read. The Cygwin case shows none of ~/{.bash_profile,.bash_login,.profile,.bashrc} are read. Doesn't this seem like a bug? Tests