How to source correct startup scripts on interactive, non-login shell
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I'm trying to set up a sane/usable environment in a barebones OpenSolaris-derivative (OmniOS, a distribution of Illumos/OpenIndiana). I have all the plumbing code I need in .profile, .inputrc, and .bashrc files ready to promote to system-wide use, but no system-wide scripts are being sourced for non-login shells. Bash attempts to load the user's .bashrc file on su, but $HOME (and any other environment variables) remains configured for the previous user.
Output from a direct (SSH) login:
login as: myuser
Using keyboard-interactive authentication.
Password:
/etc/profile run
myuser's .bashrc run
myuser's .profile run
myuser@Helios:~$ echo ~
/home/myuser
myuser@Helios:~$
Output switching user:
root@Helios:/etc# su myuser
bash: /root/.bashrc: Permission denied
bash-4.2$ id
uid=1001(myuser) gid=100(users) groups=100(users),27(sudo)
bash-4.2$ echo ~
/root
bash-4.2$
Note in particular the attempt to source root's .bashrc instead of myuser's .bashrc.
su (without additional arguments) has always worked seamlessly in Ubuntu, Fedora, etc. and I intend to replicate that experience, but what can I do when no system-wide scripts run and the user's scripts cannot be found? I'm inclined to blame OmniOS's version of bash and/or su for missing something, but what exactly is the correct behavior? Can I configure/access/script additional plumbing somewhere which addresses the failure to update $HOME and other envvars?
Further notes:
- there is no man bash in OmniOS (at least not using MANPATH=/opt/omni/share/man:/opt/mysql55/man:/opt/gcc-4.4.4/man:/usr/gnu/share/man:/usr/local/man:/usr/local/share/man:/usr/man:/usr/share/man)
- /etc/bashrc and /etc/bash.bashrc never get sourced (which is expected as this is apparently a distribution-specific convention, but Ubuntu does appear to be loading these without reference from .bashrc)
environment-variables su home illumos omnios
add a comment |
I'm trying to set up a sane/usable environment in a barebones OpenSolaris-derivative (OmniOS, a distribution of Illumos/OpenIndiana). I have all the plumbing code I need in .profile, .inputrc, and .bashrc files ready to promote to system-wide use, but no system-wide scripts are being sourced for non-login shells. Bash attempts to load the user's .bashrc file on su, but $HOME (and any other environment variables) remains configured for the previous user.
Output from a direct (SSH) login:
login as: myuser
Using keyboard-interactive authentication.
Password:
/etc/profile run
myuser's .bashrc run
myuser's .profile run
myuser@Helios:~$ echo ~
/home/myuser
myuser@Helios:~$
Output switching user:
root@Helios:/etc# su myuser
bash: /root/.bashrc: Permission denied
bash-4.2$ id
uid=1001(myuser) gid=100(users) groups=100(users),27(sudo)
bash-4.2$ echo ~
/root
bash-4.2$
Note in particular the attempt to source root's .bashrc instead of myuser's .bashrc.
su (without additional arguments) has always worked seamlessly in Ubuntu, Fedora, etc. and I intend to replicate that experience, but what can I do when no system-wide scripts run and the user's scripts cannot be found? I'm inclined to blame OmniOS's version of bash and/or su for missing something, but what exactly is the correct behavior? Can I configure/access/script additional plumbing somewhere which addresses the failure to update $HOME and other envvars?
Further notes:
- there is no man bash in OmniOS (at least not using MANPATH=/opt/omni/share/man:/opt/mysql55/man:/opt/gcc-4.4.4/man:/usr/gnu/share/man:/usr/local/man:/usr/local/share/man:/usr/man:/usr/share/man)
- /etc/bashrc and /etc/bash.bashrc never get sourced (which is expected as this is apparently a distribution-specific convention, but Ubuntu does appear to be loading these without reference from .bashrc)
environment-variables su home illumos omnios
add a comment |
I'm trying to set up a sane/usable environment in a barebones OpenSolaris-derivative (OmniOS, a distribution of Illumos/OpenIndiana). I have all the plumbing code I need in .profile, .inputrc, and .bashrc files ready to promote to system-wide use, but no system-wide scripts are being sourced for non-login shells. Bash attempts to load the user's .bashrc file on su, but $HOME (and any other environment variables) remains configured for the previous user.
Output from a direct (SSH) login:
login as: myuser
Using keyboard-interactive authentication.
Password:
/etc/profile run
myuser's .bashrc run
myuser's .profile run
myuser@Helios:~$ echo ~
/home/myuser
myuser@Helios:~$
Output switching user:
root@Helios:/etc# su myuser
bash: /root/.bashrc: Permission denied
bash-4.2$ id
uid=1001(myuser) gid=100(users) groups=100(users),27(sudo)
bash-4.2$ echo ~
/root
bash-4.2$
Note in particular the attempt to source root's .bashrc instead of myuser's .bashrc.
su (without additional arguments) has always worked seamlessly in Ubuntu, Fedora, etc. and I intend to replicate that experience, but what can I do when no system-wide scripts run and the user's scripts cannot be found? I'm inclined to blame OmniOS's version of bash and/or su for missing something, but what exactly is the correct behavior? Can I configure/access/script additional plumbing somewhere which addresses the failure to update $HOME and other envvars?
Further notes:
- there is no man bash in OmniOS (at least not using MANPATH=/opt/omni/share/man:/opt/mysql55/man:/opt/gcc-4.4.4/man:/usr/gnu/share/man:/usr/local/man:/usr/local/share/man:/usr/man:/usr/share/man)
- /etc/bashrc and /etc/bash.bashrc never get sourced (which is expected as this is apparently a distribution-specific convention, but Ubuntu does appear to be loading these without reference from .bashrc)
environment-variables su home illumos omnios
I'm trying to set up a sane/usable environment in a barebones OpenSolaris-derivative (OmniOS, a distribution of Illumos/OpenIndiana). I have all the plumbing code I need in .profile, .inputrc, and .bashrc files ready to promote to system-wide use, but no system-wide scripts are being sourced for non-login shells. Bash attempts to load the user's .bashrc file on su, but $HOME (and any other environment variables) remains configured for the previous user.
Output from a direct (SSH) login:
login as: myuser
Using keyboard-interactive authentication.
Password:
/etc/profile run
myuser's .bashrc run
myuser's .profile run
myuser@Helios:~$ echo ~
/home/myuser
myuser@Helios:~$
Output switching user:
root@Helios:/etc# su myuser
bash: /root/.bashrc: Permission denied
bash-4.2$ id
uid=1001(myuser) gid=100(users) groups=100(users),27(sudo)
bash-4.2$ echo ~
/root
bash-4.2$
Note in particular the attempt to source root's .bashrc instead of myuser's .bashrc.
su (without additional arguments) has always worked seamlessly in Ubuntu, Fedora, etc. and I intend to replicate that experience, but what can I do when no system-wide scripts run and the user's scripts cannot be found? I'm inclined to blame OmniOS's version of bash and/or su for missing something, but what exactly is the correct behavior? Can I configure/access/script additional plumbing somewhere which addresses the failure to update $HOME and other envvars?
Further notes:
- there is no man bash in OmniOS (at least not using MANPATH=/opt/omni/share/man:/opt/mysql55/man:/opt/gcc-4.4.4/man:/usr/gnu/share/man:/usr/local/man:/usr/local/share/man:/usr/man:/usr/share/man)
- /etc/bashrc and /etc/bash.bashrc never get sourced (which is expected as this is apparently a distribution-specific convention, but Ubuntu does appear to be loading these without reference from .bashrc)
environment-variables su home illumos omnios
environment-variables su home illumos omnios
edited Jun 10 '15 at 19:09
user1529891
2,11562547
2,11562547
asked Jul 29 '13 at 8:09
HonoredMuleHonoredMule
1487
1487
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
The su command does not change the HOME environment variable under Solaris. That's just how it works. Under Linux and *BSD, su does reset HOME, I think it's a BSD/SysV difference. Bash is behaving perfectly normally: it tries to load ~/.bashrc, and since HOME is still /root, that's /root/.bashrc.
The idea is that when you su to root, the shell you start and other programs will still look for your configuration files in your home directory. If you wanted the environment of the target user, you'd run su -.
If you want to set HOME but otherwise leave the environment unchanged, set it explicitly.
HOME=~myuser su myuser
Whether bash loads a system-wide file is a compile-time option. That option is enabled on Ubuntu but disabled on OmniOS.
add a comment |
Is your application able to utilize SMF? If so, it might be easier to set up a service for the application.
I've seen a Python script that will make it very easy to generate an XML for SMF to utilize:
Manifold
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f84779%2fhow-to-source-correct-startup-scripts-on-interactive-non-login-shell%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The su command does not change the HOME environment variable under Solaris. That's just how it works. Under Linux and *BSD, su does reset HOME, I think it's a BSD/SysV difference. Bash is behaving perfectly normally: it tries to load ~/.bashrc, and since HOME is still /root, that's /root/.bashrc.
The idea is that when you su to root, the shell you start and other programs will still look for your configuration files in your home directory. If you wanted the environment of the target user, you'd run su -.
If you want to set HOME but otherwise leave the environment unchanged, set it explicitly.
HOME=~myuser su myuser
Whether bash loads a system-wide file is a compile-time option. That option is enabled on Ubuntu but disabled on OmniOS.
add a comment |
The su command does not change the HOME environment variable under Solaris. That's just how it works. Under Linux and *BSD, su does reset HOME, I think it's a BSD/SysV difference. Bash is behaving perfectly normally: it tries to load ~/.bashrc, and since HOME is still /root, that's /root/.bashrc.
The idea is that when you su to root, the shell you start and other programs will still look for your configuration files in your home directory. If you wanted the environment of the target user, you'd run su -.
If you want to set HOME but otherwise leave the environment unchanged, set it explicitly.
HOME=~myuser su myuser
Whether bash loads a system-wide file is a compile-time option. That option is enabled on Ubuntu but disabled on OmniOS.
add a comment |
The su command does not change the HOME environment variable under Solaris. That's just how it works. Under Linux and *BSD, su does reset HOME, I think it's a BSD/SysV difference. Bash is behaving perfectly normally: it tries to load ~/.bashrc, and since HOME is still /root, that's /root/.bashrc.
The idea is that when you su to root, the shell you start and other programs will still look for your configuration files in your home directory. If you wanted the environment of the target user, you'd run su -.
If you want to set HOME but otherwise leave the environment unchanged, set it explicitly.
HOME=~myuser su myuser
Whether bash loads a system-wide file is a compile-time option. That option is enabled on Ubuntu but disabled on OmniOS.
The su command does not change the HOME environment variable under Solaris. That's just how it works. Under Linux and *BSD, su does reset HOME, I think it's a BSD/SysV difference. Bash is behaving perfectly normally: it tries to load ~/.bashrc, and since HOME is still /root, that's /root/.bashrc.
The idea is that when you su to root, the shell you start and other programs will still look for your configuration files in your home directory. If you wanted the environment of the target user, you'd run su -.
If you want to set HOME but otherwise leave the environment unchanged, set it explicitly.
HOME=~myuser su myuser
Whether bash loads a system-wide file is a compile-time option. That option is enabled on Ubuntu but disabled on OmniOS.
answered Jul 30 '13 at 1:37
GillesGilles
546k12911101624
546k12911101624
add a comment |
add a comment |
Is your application able to utilize SMF? If so, it might be easier to set up a service for the application.
I've seen a Python script that will make it very easy to generate an XML for SMF to utilize:
Manifold
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
add a comment |
Is your application able to utilize SMF? If so, it might be easier to set up a service for the application.
I've seen a Python script that will make it very easy to generate an XML for SMF to utilize:
Manifold
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
add a comment |
Is your application able to utilize SMF? If so, it might be easier to set up a service for the application.
I've seen a Python script that will make it very easy to generate an XML for SMF to utilize:
Manifold
Is your application able to utilize SMF? If so, it might be easier to set up a service for the application.
I've seen a Python script that will make it very easy to generate an XML for SMF to utilize:
Manifold
edited 1 hour ago
Rui F Ribeiro
41.9k1483142
41.9k1483142
answered Mar 15 '14 at 1:53
lmaverickbnalmaverickbna
11
11
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
add a comment |
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
3
3
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
I'm afraid you've misunderstood the question. In any case, please don't just post links to external resources, instead, explain how this script would help the OP and how they could use it.
– terdon♦
Mar 15 '14 at 2:15
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f84779%2fhow-to-source-correct-startup-scripts-on-interactive-non-login-shell%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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