Why did someone even decide that the program (the shell executable) needed to behave differently depending on "login" vs. "interactive"? If I'm executing a remote command (e.g. via ssh) I expect it to be working in the same environment that I'd be working in interactively. Maybe I need some environment variable to tell my script what "mode" we're in so that it can make some decision, but the shell not providing the same environment (aside from interactive vs. non-interactive behavior) bugs the hell out of me.
Historically, there were a collection of commands that ran on login (e.g., checking for mail, giving a security report, etc.) that you wouldn't want popping up when you were just firing up additional sessions with su or the like. I'm not saying it's perfect, but there is a logic to it.
Why did someone even decide that the program (the shell executable) needed to behave differently depending on "login" vs. "interactive"?
Just try this little experiment: disable the bash-completions package, and see how much more quickly you can open a new shell. While it might seem miniscule on your multicore multigigabyte desktop machine, on a NAS with limited resources, it can make a significant difference. And when you are scripting something (say, a nightly rsync backup), do you really need to have tab completion for git? This also applies to things you want to run once (on login) versus every time you open a new shell.
Just because you can't think of a use for something doesn't mean no one else can. Usually there is a reason for a feature, and the nice part is that nine times out of ten, when I'm looking for a way to do something I hadn't thought of before, it's already there in UNIX/Linux.
Let me put it another way: don't try to outthink the users' intentions- leave it to me and my scripts to decide what to run and when. My script should make the decision whether it's appropriate to load certain things. Passing --interactive, --login, --remote, --wtfe to the shell should cause nothing more than a flag to be set for my script to query. Then my script can make the decision what to load and when.
I do understand the original intent. I believe it was the wrong was to go about it.
A login shell parses .login (on login), and .logout (on logout), where an interactive shell does not, IIRC. This allows you to things like display certain information to the screen on login that you might not care about on a non-login interactive shell. E.g. running 'fortune' when you log in.
Comments
Why did someone even decide that the program (the shell executable) needed to behave differently depending on "login" vs. "interactive"? If I'm executing a remote command (e.g. via ssh) I expect it to be working in the same environment that I'd be working in interactively. Maybe I need some environment variable to tell my script what "mode" we're in so that it can make some decision, but the shell not providing the same environment (aside from interactive vs. non-interactive behavior) bugs the hell out of me.
Historically, there were a collection of commands that ran on login (e.g., checking for mail, giving a security report, etc.) that you wouldn't want popping up when you were just firing up additional sessions with su or the like. I'm not saying it's perfect, but there is a logic to it.
Why did someone even decide that the program (the shell executable) needed to behave differently depending on "login" vs. "interactive"?
Just try this little experiment: disable the bash-completions package, and see how much more quickly you can open a new shell. While it might seem miniscule on your multicore multigigabyte desktop machine, on a NAS with limited resources, it can make a significant difference. And when you are scripting something (say, a nightly rsync backup), do you really need to have tab completion for git? This also applies to things you want to run once (on login) versus every time you open a new shell.
Just because you can't think of a use for something doesn't mean no one else can. Usually there is a reason for a feature, and the nice part is that nine times out of ten, when I'm looking for a way to do something I hadn't thought of before, it's already there in UNIX/Linux.
I'm replying to the answers to my post here.
Let me put it another way: don't try to outthink the users' intentions- leave it to me and my scripts to decide what to run and when. My script should make the decision whether it's appropriate to load certain things. Passing --interactive, --login, --remote, --wtfe to the shell should cause nothing more than a flag to be set for my script to query. Then my script can make the decision what to load and when.
I do understand the original intent. I believe it was the wrong was to go about it.
A login shell parses .login (on login), and .logout (on logout), where an interactive shell does not, IIRC. This allows you to things like display certain information to the screen on login that you might not care about on a non-login interactive shell. E.g. running 'fortune' when you log in.