Scripts in /etc/profile.d Being Ignored?












54















I'm new to Ubuntu. I'm running 13.10 Desktop.



I wanted to set some system wide aliases and a custom prompt for bash. I found this article:



https://help.ubuntu.com/community/EnvironmentVariables



Following the advice in this article, I created /etc/profiles.d/profile_local.sh. It is owned by root and has permissions of 644 just like the other scripts there:



root@ubuntu:/etc/profile.d# ll
total 28
drwxr-xr-x 2 root root 4096 Mar 23 08:56 .
drwxr-xr-x 135 root root 12288 Mar 23 09:15 ..
-rw-r--r-- 1 root root 660 Oct 23 2012 bash_completion.sh
-rw-r--r-- 1 root root 3317 Mar 23 07:36 profile_local.sh
-rw-r--r-- 1 root root 1947 Nov 23 00:57 vte.sh


I have further confirmed that /etc/profile calls /etc/profile.d. It contains this code block:



if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi


Upon login, it does not appear that the custom script, profile_local.sh I created gets sourced. However if after login I 'source /etc.profile.d/profile_local.sh', I get the expected behavior, my custom aliases, and custom prompt.



What am I doing wrong?



Contents of script 'profile_local.sh':



# 3/23/14 - Copied from Gentoo /etc/bash/bashrc
# Placed in /etc/profile.d as described at:
# https://help.ubuntu.com/community/EnvironmentVariables

# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output. So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell. There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
# Shell is non-interactive. Be done now!
return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control. #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Enable history appending instead of overwriting. #139609
shopt -s histappend

# Change the window title of X terminals
case ${TERM} in
xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)
PROMPT_COMMAND='echo -ne "33]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}07"'
;;
screen)
PROMPT_COMMAND='echo -ne "33_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}33\"'
;;
esac

use_color=false

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS. Try to use the external file
# first to take advantage of user additions. Use internal bash
# globbing instead of external grep binary.
safe_term=${TERM//[^[:alnum:]]/?} # sanitize TERM
match_lhs=""
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs} ]]
&& type -P dircolors >/dev/null
&& match_lhs=$(dircolors --print-database)
[[ $'n'${match_lhs} == *$'n'"TERM "${safe_term}* ]] && use_color=true

if ${use_color} ; then
# Enable colors for ls, etc. Prefer ~/.dir_colors #64489
if type -P dircolors >/dev/null ; then
if [[ -f ~/.dir_colors ]] ; then
eval $(dircolors -b ~/.dir_colors)
elif [[ -f /etc/DIR_COLORS ]] ; then
eval $(dircolors -b /etc/DIR_COLORS)
fi
fi

if [[ ${EUID} == 0 ]] ; then
PS1='[33[01;31m]h[33[01;34m] W $[33[00m] '
else
PS1='[33[01;32m]u@h[33[01;34m] w $[33[00m] '
fi

alias ls='ls --color=auto'
alias grep='grep --colour=auto'
else
if [[ ${EUID} == 0 ]] ; then
# show root@ when we don't have colors
PS1='u@h W $ '
else
PS1='u@h w $ '
fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

TZ="PST8PDT"

alias ll='ls -la'
alias dig='dig +search'
alias dir='ls -ba'

alias edit="ee"
alias ss="ps -aux"
alias dot='ls .[a-zA-Z0-9_]*'
alias news="xterm -g 80x45 -e trn -e -S1 -N &"

alias more="less"
alias c="clear"
alias m="more"
alias j="jobs"

# common misspellings
alias mroe=more
alias pdw=pwd









share|improve this question




















  • 1





    No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

    – Drew
    Mar 23 '14 at 17:38






  • 1





    This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

    – terdon
    Mar 23 '14 at 17:41








  • 1





    Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

    – terdon
    Mar 23 '14 at 17:46








  • 1





    Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

    – terdon
    Mar 23 '14 at 17:52






  • 3





    Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

    – terdon
    Mar 23 '14 at 17:57
















54















I'm new to Ubuntu. I'm running 13.10 Desktop.



I wanted to set some system wide aliases and a custom prompt for bash. I found this article:



https://help.ubuntu.com/community/EnvironmentVariables



Following the advice in this article, I created /etc/profiles.d/profile_local.sh. It is owned by root and has permissions of 644 just like the other scripts there:



root@ubuntu:/etc/profile.d# ll
total 28
drwxr-xr-x 2 root root 4096 Mar 23 08:56 .
drwxr-xr-x 135 root root 12288 Mar 23 09:15 ..
-rw-r--r-- 1 root root 660 Oct 23 2012 bash_completion.sh
-rw-r--r-- 1 root root 3317 Mar 23 07:36 profile_local.sh
-rw-r--r-- 1 root root 1947 Nov 23 00:57 vte.sh


I have further confirmed that /etc/profile calls /etc/profile.d. It contains this code block:



if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi


Upon login, it does not appear that the custom script, profile_local.sh I created gets sourced. However if after login I 'source /etc.profile.d/profile_local.sh', I get the expected behavior, my custom aliases, and custom prompt.



What am I doing wrong?



Contents of script 'profile_local.sh':



# 3/23/14 - Copied from Gentoo /etc/bash/bashrc
# Placed in /etc/profile.d as described at:
# https://help.ubuntu.com/community/EnvironmentVariables

# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output. So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell. There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
# Shell is non-interactive. Be done now!
return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control. #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Enable history appending instead of overwriting. #139609
shopt -s histappend

# Change the window title of X terminals
case ${TERM} in
xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)
PROMPT_COMMAND='echo -ne "33]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}07"'
;;
screen)
PROMPT_COMMAND='echo -ne "33_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}33\"'
;;
esac

use_color=false

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS. Try to use the external file
# first to take advantage of user additions. Use internal bash
# globbing instead of external grep binary.
safe_term=${TERM//[^[:alnum:]]/?} # sanitize TERM
match_lhs=""
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs} ]]
&& type -P dircolors >/dev/null
&& match_lhs=$(dircolors --print-database)
[[ $'n'${match_lhs} == *$'n'"TERM "${safe_term}* ]] && use_color=true

if ${use_color} ; then
# Enable colors for ls, etc. Prefer ~/.dir_colors #64489
if type -P dircolors >/dev/null ; then
if [[ -f ~/.dir_colors ]] ; then
eval $(dircolors -b ~/.dir_colors)
elif [[ -f /etc/DIR_COLORS ]] ; then
eval $(dircolors -b /etc/DIR_COLORS)
fi
fi

if [[ ${EUID} == 0 ]] ; then
PS1='[33[01;31m]h[33[01;34m] W $[33[00m] '
else
PS1='[33[01;32m]u@h[33[01;34m] w $[33[00m] '
fi

alias ls='ls --color=auto'
alias grep='grep --colour=auto'
else
if [[ ${EUID} == 0 ]] ; then
# show root@ when we don't have colors
PS1='u@h W $ '
else
PS1='u@h w $ '
fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

TZ="PST8PDT"

alias ll='ls -la'
alias dig='dig +search'
alias dir='ls -ba'

alias edit="ee"
alias ss="ps -aux"
alias dot='ls .[a-zA-Z0-9_]*'
alias news="xterm -g 80x45 -e trn -e -S1 -N &"

alias more="less"
alias c="clear"
alias m="more"
alias j="jobs"

# common misspellings
alias mroe=more
alias pdw=pwd









share|improve this question




















  • 1





    No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

    – Drew
    Mar 23 '14 at 17:38






  • 1





    This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

    – terdon
    Mar 23 '14 at 17:41








  • 1





    Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

    – terdon
    Mar 23 '14 at 17:46








  • 1





    Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

    – terdon
    Mar 23 '14 at 17:52






  • 3





    Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

    – terdon
    Mar 23 '14 at 17:57














54












54








54


31






I'm new to Ubuntu. I'm running 13.10 Desktop.



I wanted to set some system wide aliases and a custom prompt for bash. I found this article:



https://help.ubuntu.com/community/EnvironmentVariables



Following the advice in this article, I created /etc/profiles.d/profile_local.sh. It is owned by root and has permissions of 644 just like the other scripts there:



root@ubuntu:/etc/profile.d# ll
total 28
drwxr-xr-x 2 root root 4096 Mar 23 08:56 .
drwxr-xr-x 135 root root 12288 Mar 23 09:15 ..
-rw-r--r-- 1 root root 660 Oct 23 2012 bash_completion.sh
-rw-r--r-- 1 root root 3317 Mar 23 07:36 profile_local.sh
-rw-r--r-- 1 root root 1947 Nov 23 00:57 vte.sh


I have further confirmed that /etc/profile calls /etc/profile.d. It contains this code block:



if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi


Upon login, it does not appear that the custom script, profile_local.sh I created gets sourced. However if after login I 'source /etc.profile.d/profile_local.sh', I get the expected behavior, my custom aliases, and custom prompt.



What am I doing wrong?



Contents of script 'profile_local.sh':



# 3/23/14 - Copied from Gentoo /etc/bash/bashrc
# Placed in /etc/profile.d as described at:
# https://help.ubuntu.com/community/EnvironmentVariables

# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output. So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell. There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
# Shell is non-interactive. Be done now!
return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control. #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Enable history appending instead of overwriting. #139609
shopt -s histappend

# Change the window title of X terminals
case ${TERM} in
xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)
PROMPT_COMMAND='echo -ne "33]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}07"'
;;
screen)
PROMPT_COMMAND='echo -ne "33_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}33\"'
;;
esac

use_color=false

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS. Try to use the external file
# first to take advantage of user additions. Use internal bash
# globbing instead of external grep binary.
safe_term=${TERM//[^[:alnum:]]/?} # sanitize TERM
match_lhs=""
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs} ]]
&& type -P dircolors >/dev/null
&& match_lhs=$(dircolors --print-database)
[[ $'n'${match_lhs} == *$'n'"TERM "${safe_term}* ]] && use_color=true

if ${use_color} ; then
# Enable colors for ls, etc. Prefer ~/.dir_colors #64489
if type -P dircolors >/dev/null ; then
if [[ -f ~/.dir_colors ]] ; then
eval $(dircolors -b ~/.dir_colors)
elif [[ -f /etc/DIR_COLORS ]] ; then
eval $(dircolors -b /etc/DIR_COLORS)
fi
fi

if [[ ${EUID} == 0 ]] ; then
PS1='[33[01;31m]h[33[01;34m] W $[33[00m] '
else
PS1='[33[01;32m]u@h[33[01;34m] w $[33[00m] '
fi

alias ls='ls --color=auto'
alias grep='grep --colour=auto'
else
if [[ ${EUID} == 0 ]] ; then
# show root@ when we don't have colors
PS1='u@h W $ '
else
PS1='u@h w $ '
fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

TZ="PST8PDT"

alias ll='ls -la'
alias dig='dig +search'
alias dir='ls -ba'

alias edit="ee"
alias ss="ps -aux"
alias dot='ls .[a-zA-Z0-9_]*'
alias news="xterm -g 80x45 -e trn -e -S1 -N &"

alias more="less"
alias c="clear"
alias m="more"
alias j="jobs"

# common misspellings
alias mroe=more
alias pdw=pwd









share|improve this question
















I'm new to Ubuntu. I'm running 13.10 Desktop.



I wanted to set some system wide aliases and a custom prompt for bash. I found this article:



https://help.ubuntu.com/community/EnvironmentVariables



Following the advice in this article, I created /etc/profiles.d/profile_local.sh. It is owned by root and has permissions of 644 just like the other scripts there:



root@ubuntu:/etc/profile.d# ll
total 28
drwxr-xr-x 2 root root 4096 Mar 23 08:56 .
drwxr-xr-x 135 root root 12288 Mar 23 09:15 ..
-rw-r--r-- 1 root root 660 Oct 23 2012 bash_completion.sh
-rw-r--r-- 1 root root 3317 Mar 23 07:36 profile_local.sh
-rw-r--r-- 1 root root 1947 Nov 23 00:57 vte.sh


I have further confirmed that /etc/profile calls /etc/profile.d. It contains this code block:



if [ -d /etc/profile.d ]; then
for i in /etc/profile.d/*.sh; do
if [ -r $i ]; then
. $i
fi
done
unset i
fi


Upon login, it does not appear that the custom script, profile_local.sh I created gets sourced. However if after login I 'source /etc.profile.d/profile_local.sh', I get the expected behavior, my custom aliases, and custom prompt.



What am I doing wrong?



Contents of script 'profile_local.sh':



# 3/23/14 - Copied from Gentoo /etc/bash/bashrc
# Placed in /etc/profile.d as described at:
# https://help.ubuntu.com/community/EnvironmentVariables

# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output. So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell. There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
# Shell is non-interactive. Be done now!
return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control. #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Enable history appending instead of overwriting. #139609
shopt -s histappend

# Change the window title of X terminals
case ${TERM} in
xterm*|rxvt*|Eterm|aterm|kterm|gnome*|interix)
PROMPT_COMMAND='echo -ne "33]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}07"'
;;
screen)
PROMPT_COMMAND='echo -ne "33_${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}33\"'
;;
esac

use_color=false

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS. Try to use the external file
# first to take advantage of user additions. Use internal bash
# globbing instead of external grep binary.
safe_term=${TERM//[^[:alnum:]]/?} # sanitize TERM
match_lhs=""
[[ -f ~/.dir_colors ]] && match_lhs="${match_lhs}$(<~/.dir_colors)"
[[ -f /etc/DIR_COLORS ]] && match_lhs="${match_lhs}$(</etc/DIR_COLORS)"
[[ -z ${match_lhs} ]]
&& type -P dircolors >/dev/null
&& match_lhs=$(dircolors --print-database)
[[ $'n'${match_lhs} == *$'n'"TERM "${safe_term}* ]] && use_color=true

if ${use_color} ; then
# Enable colors for ls, etc. Prefer ~/.dir_colors #64489
if type -P dircolors >/dev/null ; then
if [[ -f ~/.dir_colors ]] ; then
eval $(dircolors -b ~/.dir_colors)
elif [[ -f /etc/DIR_COLORS ]] ; then
eval $(dircolors -b /etc/DIR_COLORS)
fi
fi

if [[ ${EUID} == 0 ]] ; then
PS1='[33[01;31m]h[33[01;34m] W $[33[00m] '
else
PS1='[33[01;32m]u@h[33[01;34m] w $[33[00m] '
fi

alias ls='ls --color=auto'
alias grep='grep --colour=auto'
else
if [[ ${EUID} == 0 ]] ; then
# show root@ when we don't have colors
PS1='u@h W $ '
else
PS1='u@h w $ '
fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term match_lhs

TZ="PST8PDT"

alias ll='ls -la'
alias dig='dig +search'
alias dir='ls -ba'

alias edit="ee"
alias ss="ps -aux"
alias dot='ls .[a-zA-Z0-9_]*'
alias news="xterm -g 80x45 -e trn -e -S1 -N &"

alias more="less"
alias c="clear"
alias m="more"
alias j="jobs"

# common misspellings
alias mroe=more
alias pdw=pwd






bash .profile






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 9 '14 at 17:48









Braiam

52.3k20138223




52.3k20138223










asked Mar 23 '14 at 16:55









DrewDrew

276146




276146








  • 1





    No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

    – Drew
    Mar 23 '14 at 17:38






  • 1





    This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

    – terdon
    Mar 23 '14 at 17:41








  • 1





    Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

    – terdon
    Mar 23 '14 at 17:46








  • 1





    Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

    – terdon
    Mar 23 '14 at 17:52






  • 3





    Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

    – terdon
    Mar 23 '14 at 17:57














  • 1





    No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

    – Drew
    Mar 23 '14 at 17:38






  • 1





    This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

    – terdon
    Mar 23 '14 at 17:41








  • 1





    Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

    – terdon
    Mar 23 '14 at 17:46








  • 1





    Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

    – terdon
    Mar 23 '14 at 17:52






  • 3





    Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

    – terdon
    Mar 23 '14 at 17:57








1




1





No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

– Drew
Mar 23 '14 at 17:38





No, it's not executable but neither are the other two scripts. However I changed it and tried again. Still no luck.

– Drew
Mar 23 '14 at 17:38




1




1





This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

– terdon
Mar 23 '14 at 17:41







This has nothing to do with adding .sh, it is irrelevant and anyway the files in profile.d are sourced, not executed which is slightly different and does not require the file to be executable. The issue here is that profile &co are not read by non-login scripts.

– terdon
Mar 23 '14 at 17:41






1




1





Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

– terdon
Mar 23 '14 at 17:46







Drew, read my answer. The profile files are ignored by non-login shells but Ubuntu's default GUI login will read some of them. Just use .bashrc and all your problems will go away. There is also a question of precedence, if one of the files that are read subsequently also sets PS1, then the previous value will be discarded. Anyway, seriously, don't touch the filers in /etc, play with the ones in your home dir and use .bashrc not profile.

– terdon
Mar 23 '14 at 17:46






1




1





Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

– terdon
Mar 23 '14 at 17:52





Yes, that should be a login shell (that's the kind if thing you should include in your question next time). However, most systems have default .profile files in your home and the settings there will overwrite anything you do in /etc/profile. Basically never touch /etc unless you know what you're doing. That's what the user-specific files are for. Also, please edit your question and explain exactly how you are connecting, that changes everything.

– terdon
Mar 23 '14 at 17:52




3




3





Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

– terdon
Mar 23 '14 at 17:57





Please don't do this using /etc/profile.d that is a really bad idea and will affect all users of the system. Just include the commands from profile_local.sh in your ~/.profile or simply source the script by adding this line to your ~/.profile : . /path/to/profile_local.sh. (the . means source, it will read the file you give it and run the commands it finds there).

– terdon
Mar 23 '14 at 17:57










4 Answers
4






active

oldest

votes


















99














To understand what's going on here, you need to understand a little background information about how shells (bash in this case) are run.




  • When you open a terminal emulator (gnome-terminal for example), you are executing what is known as an interactive, non-login shell.


  • When you log into your machine from the command line, via ssh, or run a command such as su - username, you are running an interactive login shell.


  • When you log in graphically, you are running something completely different, the details will depend on your system and graphical environment but in general it is the graphical shell that deals with your login. While many graphical shells (including the Ubuntu default) will read /etc/profile not all of them do.


  • Finally, when you run a shell script, it is run in a non-interactive, non-login shell.



Now, the files that bash will read when launched depend on the type of shell it is running as. The following is an excerpt of the INVOCATION section of man bash (emphasis mine):




When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
in that order
, and reads and executes commands from the first one that
exists and is readable. The --noprofile option may be used when the
shell is started to inhibit this behavior.



When an interactive shell that is not a login shell is started, bash
reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
these files exist. This may be inhibited by using the --norc option.
The --rcfile file option will force bash to read and execute commands
from file instead of /etc/bash.bashrc and ~/.bashrc.




What all this means is that you are editing the wrong file. You can test this by dropping to a virtual console using Ctrl+Alt+F2 (return to the GUI with Alt+F7, or F8 depending on your setup) and logging in there. You will see that your prompt and aliases are available.



So, in order to have the setting you want applied to non-login shells, the type you get each time you open a terminal, you should make your changes to ~/.bashrc instead. Alternatively, you can also place your aliases in the file ~/.bash_aliases (however, note that this is an Ubuntu feature and you should not expect it to work on other distributions).



For more details on which file should be used for what, see here.





NOTES:




  • Debian (and by extension Ubuntu) also has the default ~/.profile source ~/.bashrc. This means that any changes you make to ~/.bashrc will also be inherited by login shells but i) this is not the case in all Linux/Unix machines and ii) the inverse is not true which is why you should generally always work with ~/.bashrc &co rather than ~/.profile or /etc/profile.


  • Also, a general note on usage, changes made to the configuration files in /etc will affect all users. This is usually not what you want to do and should be avoided. You should always use the equivalent files in your home directory (~/).



  • The various configuration files are read sequentially. Specifically, for login shells, the order is:



    /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.profile


    This means that any setting in ~/.profile will overwrite anything set in the previous files.








share|improve this answer





















  • 1





    According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

    – stackoverflower
    Mar 22 '15 at 16:36













  • @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

    – terdon
    Mar 22 '15 at 16:40











  • magnificant post, wonder why it didn't show up on google when I had the same problem

    – Donato
    May 26 '15 at 15:09











  • @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

    – Eliah Kagan
    Jul 25 '17 at 21:11



















1














Another possibility, especially for settings like the history settings HISTSIZE, HISTFILESIZE, HISTCONTROL, and PS1 is that the files are being loaded, but settings are overwritten in another file that is source later, with the most likely culprit being ~/.bashrc. (I have a default set of settings for our servers, like a prompt that is red for root to warn the user and large histories with timestamps)



The default Ubuntu .bashrc from /etc/skel sets several settings, which might have made sense to set from somewhere where it would not override settings set by the system owner from /etc/profile.d (Like /etc/bash.bashrc) (If a user edits their .bashrc, it is fine to overwrite settings, the system default files are more annoying)






share|improve this answer































    1














    Open Edit -> Preferences
    in first tab "General", under label "Command", enable "Run command as login shell"



    KISS



    ==Mac





    share








    New contributor




    Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




























      -1














      VERSION="16.04.3 LTS (Xenial Xerus)"



      Okay so everyone has assumed that the person here doesn't want /etc/profile.d/somefile.sh for all users, but in my case that's exactly what I wanted.



      So actually as it turns out with Ubuntu if you use this and you want it to take effect in your graphical shell, all you have to do is set the file and then logout and back in again. All your consoles or anything you launch whether it be xterm type or console type (Or dropping to the shell) will now have that file sourced.



      No need to use .bashrc etc for all users. Sorry this just wasn't clear in above answer. Everything they said is true but in reality its mostly not true as everything the windows manager launches will inherit these settings so just re-login and solve your issue and don't bother with .bashrc etc if your intention is to apply it to all users.






      share|improve this answer





















      • 1





        My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

        – Thomas Arildsen
        Oct 1 '18 at 11:57











      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f438150%2fscripts-in-etc-profile-d-being-ignored%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      99














      To understand what's going on here, you need to understand a little background information about how shells (bash in this case) are run.




      • When you open a terminal emulator (gnome-terminal for example), you are executing what is known as an interactive, non-login shell.


      • When you log into your machine from the command line, via ssh, or run a command such as su - username, you are running an interactive login shell.


      • When you log in graphically, you are running something completely different, the details will depend on your system and graphical environment but in general it is the graphical shell that deals with your login. While many graphical shells (including the Ubuntu default) will read /etc/profile not all of them do.


      • Finally, when you run a shell script, it is run in a non-interactive, non-login shell.



      Now, the files that bash will read when launched depend on the type of shell it is running as. The following is an excerpt of the INVOCATION section of man bash (emphasis mine):




      When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading
      that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
      in that order
      , and reads and executes commands from the first one that
      exists and is readable. The --noprofile option may be used when the
      shell is started to inhibit this behavior.



      When an interactive shell that is not a login shell is started, bash
      reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
      these files exist. This may be inhibited by using the --norc option.
      The --rcfile file option will force bash to read and execute commands
      from file instead of /etc/bash.bashrc and ~/.bashrc.




      What all this means is that you are editing the wrong file. You can test this by dropping to a virtual console using Ctrl+Alt+F2 (return to the GUI with Alt+F7, or F8 depending on your setup) and logging in there. You will see that your prompt and aliases are available.



      So, in order to have the setting you want applied to non-login shells, the type you get each time you open a terminal, you should make your changes to ~/.bashrc instead. Alternatively, you can also place your aliases in the file ~/.bash_aliases (however, note that this is an Ubuntu feature and you should not expect it to work on other distributions).



      For more details on which file should be used for what, see here.





      NOTES:




      • Debian (and by extension Ubuntu) also has the default ~/.profile source ~/.bashrc. This means that any changes you make to ~/.bashrc will also be inherited by login shells but i) this is not the case in all Linux/Unix machines and ii) the inverse is not true which is why you should generally always work with ~/.bashrc &co rather than ~/.profile or /etc/profile.


      • Also, a general note on usage, changes made to the configuration files in /etc will affect all users. This is usually not what you want to do and should be avoided. You should always use the equivalent files in your home directory (~/).



      • The various configuration files are read sequentially. Specifically, for login shells, the order is:



        /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.profile


        This means that any setting in ~/.profile will overwrite anything set in the previous files.








      share|improve this answer





















      • 1





        According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

        – stackoverflower
        Mar 22 '15 at 16:36













      • @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

        – terdon
        Mar 22 '15 at 16:40











      • magnificant post, wonder why it didn't show up on google when I had the same problem

        – Donato
        May 26 '15 at 15:09











      • @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

        – Eliah Kagan
        Jul 25 '17 at 21:11
















      99














      To understand what's going on here, you need to understand a little background information about how shells (bash in this case) are run.




      • When you open a terminal emulator (gnome-terminal for example), you are executing what is known as an interactive, non-login shell.


      • When you log into your machine from the command line, via ssh, or run a command such as su - username, you are running an interactive login shell.


      • When you log in graphically, you are running something completely different, the details will depend on your system and graphical environment but in general it is the graphical shell that deals with your login. While many graphical shells (including the Ubuntu default) will read /etc/profile not all of them do.


      • Finally, when you run a shell script, it is run in a non-interactive, non-login shell.



      Now, the files that bash will read when launched depend on the type of shell it is running as. The following is an excerpt of the INVOCATION section of man bash (emphasis mine):




      When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading
      that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
      in that order
      , and reads and executes commands from the first one that
      exists and is readable. The --noprofile option may be used when the
      shell is started to inhibit this behavior.



      When an interactive shell that is not a login shell is started, bash
      reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
      these files exist. This may be inhibited by using the --norc option.
      The --rcfile file option will force bash to read and execute commands
      from file instead of /etc/bash.bashrc and ~/.bashrc.




      What all this means is that you are editing the wrong file. You can test this by dropping to a virtual console using Ctrl+Alt+F2 (return to the GUI with Alt+F7, or F8 depending on your setup) and logging in there. You will see that your prompt and aliases are available.



      So, in order to have the setting you want applied to non-login shells, the type you get each time you open a terminal, you should make your changes to ~/.bashrc instead. Alternatively, you can also place your aliases in the file ~/.bash_aliases (however, note that this is an Ubuntu feature and you should not expect it to work on other distributions).



      For more details on which file should be used for what, see here.





      NOTES:




      • Debian (and by extension Ubuntu) also has the default ~/.profile source ~/.bashrc. This means that any changes you make to ~/.bashrc will also be inherited by login shells but i) this is not the case in all Linux/Unix machines and ii) the inverse is not true which is why you should generally always work with ~/.bashrc &co rather than ~/.profile or /etc/profile.


      • Also, a general note on usage, changes made to the configuration files in /etc will affect all users. This is usually not what you want to do and should be avoided. You should always use the equivalent files in your home directory (~/).



      • The various configuration files are read sequentially. Specifically, for login shells, the order is:



        /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.profile


        This means that any setting in ~/.profile will overwrite anything set in the previous files.








      share|improve this answer





















      • 1





        According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

        – stackoverflower
        Mar 22 '15 at 16:36













      • @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

        – terdon
        Mar 22 '15 at 16:40











      • magnificant post, wonder why it didn't show up on google when I had the same problem

        – Donato
        May 26 '15 at 15:09











      • @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

        – Eliah Kagan
        Jul 25 '17 at 21:11














      99












      99








      99







      To understand what's going on here, you need to understand a little background information about how shells (bash in this case) are run.




      • When you open a terminal emulator (gnome-terminal for example), you are executing what is known as an interactive, non-login shell.


      • When you log into your machine from the command line, via ssh, or run a command such as su - username, you are running an interactive login shell.


      • When you log in graphically, you are running something completely different, the details will depend on your system and graphical environment but in general it is the graphical shell that deals with your login. While many graphical shells (including the Ubuntu default) will read /etc/profile not all of them do.


      • Finally, when you run a shell script, it is run in a non-interactive, non-login shell.



      Now, the files that bash will read when launched depend on the type of shell it is running as. The following is an excerpt of the INVOCATION section of man bash (emphasis mine):




      When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading
      that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
      in that order
      , and reads and executes commands from the first one that
      exists and is readable. The --noprofile option may be used when the
      shell is started to inhibit this behavior.



      When an interactive shell that is not a login shell is started, bash
      reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
      these files exist. This may be inhibited by using the --norc option.
      The --rcfile file option will force bash to read and execute commands
      from file instead of /etc/bash.bashrc and ~/.bashrc.




      What all this means is that you are editing the wrong file. You can test this by dropping to a virtual console using Ctrl+Alt+F2 (return to the GUI with Alt+F7, or F8 depending on your setup) and logging in there. You will see that your prompt and aliases are available.



      So, in order to have the setting you want applied to non-login shells, the type you get each time you open a terminal, you should make your changes to ~/.bashrc instead. Alternatively, you can also place your aliases in the file ~/.bash_aliases (however, note that this is an Ubuntu feature and you should not expect it to work on other distributions).



      For more details on which file should be used for what, see here.





      NOTES:




      • Debian (and by extension Ubuntu) also has the default ~/.profile source ~/.bashrc. This means that any changes you make to ~/.bashrc will also be inherited by login shells but i) this is not the case in all Linux/Unix machines and ii) the inverse is not true which is why you should generally always work with ~/.bashrc &co rather than ~/.profile or /etc/profile.


      • Also, a general note on usage, changes made to the configuration files in /etc will affect all users. This is usually not what you want to do and should be avoided. You should always use the equivalent files in your home directory (~/).



      • The various configuration files are read sequentially. Specifically, for login shells, the order is:



        /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.profile


        This means that any setting in ~/.profile will overwrite anything set in the previous files.








      share|improve this answer















      To understand what's going on here, you need to understand a little background information about how shells (bash in this case) are run.




      • When you open a terminal emulator (gnome-terminal for example), you are executing what is known as an interactive, non-login shell.


      • When you log into your machine from the command line, via ssh, or run a command such as su - username, you are running an interactive login shell.


      • When you log in graphically, you are running something completely different, the details will depend on your system and graphical environment but in general it is the graphical shell that deals with your login. While many graphical shells (including the Ubuntu default) will read /etc/profile not all of them do.


      • Finally, when you run a shell script, it is run in a non-interactive, non-login shell.



      Now, the files that bash will read when launched depend on the type of shell it is running as. The following is an excerpt of the INVOCATION section of man bash (emphasis mine):




      When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading
      that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile,
      in that order
      , and reads and executes commands from the first one that
      exists and is readable. The --noprofile option may be used when the
      shell is started to inhibit this behavior.



      When an interactive shell that is not a login shell is started, bash
      reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
      these files exist. This may be inhibited by using the --norc option.
      The --rcfile file option will force bash to read and execute commands
      from file instead of /etc/bash.bashrc and ~/.bashrc.




      What all this means is that you are editing the wrong file. You can test this by dropping to a virtual console using Ctrl+Alt+F2 (return to the GUI with Alt+F7, or F8 depending on your setup) and logging in there. You will see that your prompt and aliases are available.



      So, in order to have the setting you want applied to non-login shells, the type you get each time you open a terminal, you should make your changes to ~/.bashrc instead. Alternatively, you can also place your aliases in the file ~/.bash_aliases (however, note that this is an Ubuntu feature and you should not expect it to work on other distributions).



      For more details on which file should be used for what, see here.





      NOTES:




      • Debian (and by extension Ubuntu) also has the default ~/.profile source ~/.bashrc. This means that any changes you make to ~/.bashrc will also be inherited by login shells but i) this is not the case in all Linux/Unix machines and ii) the inverse is not true which is why you should generally always work with ~/.bashrc &co rather than ~/.profile or /etc/profile.


      • Also, a general note on usage, changes made to the configuration files in /etc will affect all users. This is usually not what you want to do and should be avoided. You should always use the equivalent files in your home directory (~/).



      • The various configuration files are read sequentially. Specifically, for login shells, the order is:



        /etc/profile -> /etc/profile.d/* (in alphabetical order) -> ~/.profile


        This means that any setting in ~/.profile will overwrite anything set in the previous files.









      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jul 25 '17 at 20:59









      Eliah Kagan

      82.6k22227369




      82.6k22227369










      answered Mar 23 '14 at 17:39









      terdonterdon

      66.9k12139221




      66.9k12139221








      • 1





        According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

        – stackoverflower
        Mar 22 '15 at 16:36













      • @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

        – terdon
        Mar 22 '15 at 16:40











      • magnificant post, wonder why it didn't show up on google when I had the same problem

        – Donato
        May 26 '15 at 15:09











      • @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

        – Eliah Kagan
        Jul 25 '17 at 21:11














      • 1





        According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

        – stackoverflower
        Mar 22 '15 at 16:36













      • @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

        – terdon
        Mar 22 '15 at 16:40











      • magnificant post, wonder why it didn't show up on google when I had the same problem

        – Donato
        May 26 '15 at 15:09











      • @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

        – Eliah Kagan
        Jul 25 '17 at 21:11








      1




      1





      According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

      – stackoverflower
      Mar 22 '15 at 16:36







      According to this post howtolamp.com/articles/…, you can also run echo $0 from a terminal and if the output is prefixed with a "-" then you are in a login shell.

      – stackoverflower
      Mar 22 '15 at 16:36















      @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

      – terdon
      Mar 22 '15 at 16:40





      @stackoverflower not on my system. That works for a remote, interactive login shell. Doesn't seem to when running bash -l. In any case, why is that relevant? The question is not about how to check what type of shell you're running.

      – terdon
      Mar 22 '15 at 16:40













      magnificant post, wonder why it didn't show up on google when I had the same problem

      – Donato
      May 26 '15 at 15:09





      magnificant post, wonder why it didn't show up on google when I had the same problem

      – Donato
      May 26 '15 at 15:09













      @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

      – Eliah Kagan
      Jul 25 '17 at 21:11





      @stackoverflower If "$0" expands to something that starts with -, then you know you have a login shell. But the converse is not true: the absence of - doesn't ensure you're not in a login shell. Most common ways of starting login shells do give you a leading -, but not all. man bash tells us "A login shell is one whose first character of argument zero is a -, or one started with the --login option." (-l is the short form of --login; they're equivalent.) In Bash you can run shopt login_shell to check.

      – Eliah Kagan
      Jul 25 '17 at 21:11













      1














      Another possibility, especially for settings like the history settings HISTSIZE, HISTFILESIZE, HISTCONTROL, and PS1 is that the files are being loaded, but settings are overwritten in another file that is source later, with the most likely culprit being ~/.bashrc. (I have a default set of settings for our servers, like a prompt that is red for root to warn the user and large histories with timestamps)



      The default Ubuntu .bashrc from /etc/skel sets several settings, which might have made sense to set from somewhere where it would not override settings set by the system owner from /etc/profile.d (Like /etc/bash.bashrc) (If a user edits their .bashrc, it is fine to overwrite settings, the system default files are more annoying)






      share|improve this answer




























        1














        Another possibility, especially for settings like the history settings HISTSIZE, HISTFILESIZE, HISTCONTROL, and PS1 is that the files are being loaded, but settings are overwritten in another file that is source later, with the most likely culprit being ~/.bashrc. (I have a default set of settings for our servers, like a prompt that is red for root to warn the user and large histories with timestamps)



        The default Ubuntu .bashrc from /etc/skel sets several settings, which might have made sense to set from somewhere where it would not override settings set by the system owner from /etc/profile.d (Like /etc/bash.bashrc) (If a user edits their .bashrc, it is fine to overwrite settings, the system default files are more annoying)






        share|improve this answer


























          1












          1








          1







          Another possibility, especially for settings like the history settings HISTSIZE, HISTFILESIZE, HISTCONTROL, and PS1 is that the files are being loaded, but settings are overwritten in another file that is source later, with the most likely culprit being ~/.bashrc. (I have a default set of settings for our servers, like a prompt that is red for root to warn the user and large histories with timestamps)



          The default Ubuntu .bashrc from /etc/skel sets several settings, which might have made sense to set from somewhere where it would not override settings set by the system owner from /etc/profile.d (Like /etc/bash.bashrc) (If a user edits their .bashrc, it is fine to overwrite settings, the system default files are more annoying)






          share|improve this answer













          Another possibility, especially for settings like the history settings HISTSIZE, HISTFILESIZE, HISTCONTROL, and PS1 is that the files are being loaded, but settings are overwritten in another file that is source later, with the most likely culprit being ~/.bashrc. (I have a default set of settings for our servers, like a prompt that is red for root to warn the user and large histories with timestamps)



          The default Ubuntu .bashrc from /etc/skel sets several settings, which might have made sense to set from somewhere where it would not override settings set by the system owner from /etc/profile.d (Like /etc/bash.bashrc) (If a user edits their .bashrc, it is fine to overwrite settings, the system default files are more annoying)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Apr 10 '18 at 8:02









          Gert van den BergGert van den Berg

          1688




          1688























              1














              Open Edit -> Preferences
              in first tab "General", under label "Command", enable "Run command as login shell"



              KISS



              ==Mac





              share








              New contributor




              Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.

























                1














                Open Edit -> Preferences
                in first tab "General", under label "Command", enable "Run command as login shell"



                KISS



                ==Mac





                share








                New contributor




                Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.























                  1












                  1








                  1







                  Open Edit -> Preferences
                  in first tab "General", under label "Command", enable "Run command as login shell"



                  KISS



                  ==Mac





                  share








                  New contributor




                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.










                  Open Edit -> Preferences
                  in first tab "General", under label "Command", enable "Run command as login shell"



                  KISS



                  ==Mac






                  share








                  New contributor




                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.








                  share


                  share






                  New contributor




                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 4 hours ago









                  MacMac

                  111




                  111




                  New contributor




                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  Mac is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.























                      -1














                      VERSION="16.04.3 LTS (Xenial Xerus)"



                      Okay so everyone has assumed that the person here doesn't want /etc/profile.d/somefile.sh for all users, but in my case that's exactly what I wanted.



                      So actually as it turns out with Ubuntu if you use this and you want it to take effect in your graphical shell, all you have to do is set the file and then logout and back in again. All your consoles or anything you launch whether it be xterm type or console type (Or dropping to the shell) will now have that file sourced.



                      No need to use .bashrc etc for all users. Sorry this just wasn't clear in above answer. Everything they said is true but in reality its mostly not true as everything the windows manager launches will inherit these settings so just re-login and solve your issue and don't bother with .bashrc etc if your intention is to apply it to all users.






                      share|improve this answer





















                      • 1





                        My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                        – Thomas Arildsen
                        Oct 1 '18 at 11:57
















                      -1














                      VERSION="16.04.3 LTS (Xenial Xerus)"



                      Okay so everyone has assumed that the person here doesn't want /etc/profile.d/somefile.sh for all users, but in my case that's exactly what I wanted.



                      So actually as it turns out with Ubuntu if you use this and you want it to take effect in your graphical shell, all you have to do is set the file and then logout and back in again. All your consoles or anything you launch whether it be xterm type or console type (Or dropping to the shell) will now have that file sourced.



                      No need to use .bashrc etc for all users. Sorry this just wasn't clear in above answer. Everything they said is true but in reality its mostly not true as everything the windows manager launches will inherit these settings so just re-login and solve your issue and don't bother with .bashrc etc if your intention is to apply it to all users.






                      share|improve this answer





















                      • 1





                        My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                        – Thomas Arildsen
                        Oct 1 '18 at 11:57














                      -1












                      -1








                      -1







                      VERSION="16.04.3 LTS (Xenial Xerus)"



                      Okay so everyone has assumed that the person here doesn't want /etc/profile.d/somefile.sh for all users, but in my case that's exactly what I wanted.



                      So actually as it turns out with Ubuntu if you use this and you want it to take effect in your graphical shell, all you have to do is set the file and then logout and back in again. All your consoles or anything you launch whether it be xterm type or console type (Or dropping to the shell) will now have that file sourced.



                      No need to use .bashrc etc for all users. Sorry this just wasn't clear in above answer. Everything they said is true but in reality its mostly not true as everything the windows manager launches will inherit these settings so just re-login and solve your issue and don't bother with .bashrc etc if your intention is to apply it to all users.






                      share|improve this answer















                      VERSION="16.04.3 LTS (Xenial Xerus)"



                      Okay so everyone has assumed that the person here doesn't want /etc/profile.d/somefile.sh for all users, but in my case that's exactly what I wanted.



                      So actually as it turns out with Ubuntu if you use this and you want it to take effect in your graphical shell, all you have to do is set the file and then logout and back in again. All your consoles or anything you launch whether it be xterm type or console type (Or dropping to the shell) will now have that file sourced.



                      No need to use .bashrc etc for all users. Sorry this just wasn't clear in above answer. Everything they said is true but in reality its mostly not true as everything the windows manager launches will inherit these settings so just re-login and solve your issue and don't bother with .bashrc etc if your intention is to apply it to all users.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Jan 23 '18 at 22:42

























                      answered Jan 23 '18 at 22:21









                      Isaac Kane EgglestoneIsaac Kane Egglestone

                      111




                      111








                      • 1





                        My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                        – Thomas Arildsen
                        Oct 1 '18 at 11:57














                      • 1





                        My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                        – Thomas Arildsen
                        Oct 1 '18 at 11:57








                      1




                      1





                      My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                      – Thomas Arildsen
                      Oct 1 '18 at 11:57





                      My problem is exactly that this does not happen in the terminal run under the graphical user interface; neither in Ubuntu 16.04.3 or 18.04.

                      – Thomas Arildsen
                      Oct 1 '18 at 11:57


















                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f438150%2fscripts-in-etc-profile-d-being-ignored%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      GameSpot

                      connect to host localhost port 22: Connection refused

                      Getting a Wifi WPA2 wifi connection