4 ms·

Skimming the bash manpage every once in a while is important to stay out of information bubbles. There are too many developers who rely only on Google/Stack Ov

Skimming the bash manpage every once in a while is important to stay out of information bubbles. There are too many developers who rely only on Google/Stack Overflow to find and write answers to questions, and it's common to repeat bad, incomplete, or outdated information. I can think of a lot of times when the most accepted SO answer for many questions was "copy and paste this gigantic block of code" instead of using an existing command.

acqq 7y ago
Most of information there is not worth having in my "brain cache" at all, and especially not worth refreshing it regularly. Life is too short to even trying to remember the things like what's the difference between .bash_profile .profile .bashrc .inputrc and .bash_login (bonus point for remembering what is redirected to what in the files themselves in which distribution) or what the hell is a "login shell" and what is not. And there are many such details that are effectively useless for 99.99% of the users but they just have to survive the suffering to fix the darn thing when they have some issue. I'm sure even most of the readers here can't give a one line answer what is the "right" and "general" way to preset a darn variable for a shell. By design of all these artifacts we work with, it necessarily leads to a page-length discussion of which shells exist and what their differences are and whatnot. Such a waste of everybody's mental energy on a global level.
- 0xADEADBEE 7y ago
  I think it's a bit unfair you're being downvoted because you raise some good points. A lot of people agree POSIX is a mess and you've highlighted a fraction of reasons related to that. Would any of the downvoters care to elucidate? Maybe I'm missing something obvious.
  - __del__ 7y ago
    Not a downvoter, but I assume the reason is that many people do understand these mechanisms without evicting too much from their brain cache. Files like .bash_profile, .bash_login, .profile, .zprofile, /etc/profile, /etc/profile.d/whatever.sh all serve the same purpose, the primary aspect of which is to apply things like environment variables at login. Display managers and [login] shells source these things in a predictable precedence order so that environment variables are correctly inherited by children of GUI environment processes and login shells. Login shells? Well yeah, the point of a login shell is that it invokes login-related tasks like setting environment variables from a profile. That's intentionally separate from the behavior of interactive shells because the environments of interactive shells may have been modified intentionally and shouldn't be "reset" to the values applied at login. edit: also .inputrc is the readline configuration file for things like shortcut keys in all programs which use readline (not just bash) and .bashrc is for customizations specific to interactive shells
    - acqq 7y ago
      You see I’ve read this kind of information in exactly the words you use more than once and I still can’t summarize in one sentence where should one put his variables for things to “just work.” Locally for one user. Provided I just don’t know and don’t even care what the differences between the login and interactive shells are and that I just run the whatever terminal it is default from the GUI menu (whichever GUI it is). And your explanation what the differences are is for me still circular, exactly like in the man pages: login shell is the one which invokes login-related tasks, and I should care about the difference from the interactive shells. I still have no idea what that even means, it is what exactly happens when? Anybody knows some sane explanation of these? I admit I never tried to find it, as I tried to read the man pages, didn't find anything reasonable, but knew that it doesn't matter to me. I just want the darn variables to exists whenever I need them. I don't care about the differences. One single place is enough. But now that you say that you "do understand these mechanisms without evicting too much from" your "brain cache" I'd really like to learn everything about the differences. Specifically, when is one invoked and when another for the user "acqq", let's say, on a default Ubuntu system, and on a default Red Hat system? Are really more different user shells invoked in different forms for a single user, on a single machine, between the booting of the machine, logging in (in GUI) and then starting a few times the terminal with shell inside? When is invoked and which is invoked when? And why shouldn't be a single place for the variables I want to define? No idea, but I would be grateful to read about it now. Thanks in advance.
- __del__ 7y ago
  The general way to set an environment variable is in /etc/profile or ~/.{bash_,,z}profile. PAM uses /etc/environment, and systemd would prefer to have you set up default environment variables in /etc/systemd/system.conf. You can even pass them directly to Linux from your bootloader (unrecognized arguments on the kernel command line in the form foo=bar become environment variables), but the profiles are the generally accepted way of doing it.
  - acqq 7y ago
    It is a joke? If I want to set some variable to be present for a single user (me) I surely don't want to ever touch /etc/profile or /etc/systemd/system.conf (and I have no idea what /etc/environment is supposed to be). And even less want to change something in a bootloader. The things are surely configurable in my user home directory.
frereubu 7y ago
I see where you're coming from, but I think it's the attitude of the developer that's more important. I've learned a good deal of Bash from places like SO, but I've always tried to learn why the command is like that, and I've found other sources more useful than man. If someone is the kind of developer who blindly copies and pastes chunks of code from SO then there are bigger problems than not using man.

acqq 7y ago

Most of information there is not worth having in my "brain cache" at all, and especially not worth refreshing it regularly. Life is too short to even trying to remember the things like what's the difference between .bash_profile .profile .bashrc .inputrc and .bash_login (bonus point for remembering what is redirected to what in the files themselves in which distribution) or what the hell is a "login shell" and what is not. And there are many such details that are effectively useless for 99.99% of the users but they just have to survive the suffering to fix the darn thing when they have some issue. I'm sure even most of the readers here can't give a one line answer what is the "right" and "general" way to preset a darn variable for a shell. By design of all these artifacts we work with, it necessarily leads to a page-length discussion of which shells exist and what their differences are and whatnot. Such a waste of everybody's mental energy on a global level.

0xADEADBEE 7y ago
I think it's a bit unfair you're being downvoted because you raise some good points. A lot of people agree POSIX is a mess and you've highlighted a fraction of reasons related to that. Would any of the downvoters care to elucidate? Maybe I'm missing something obvious.
- __del__ 7y ago
  Not a downvoter, but I assume the reason is that many people do understand these mechanisms without evicting too much from their brain cache. Files like .bash_profile, .bash_login, .profile, .zprofile, /etc/profile, /etc/profile.d/whatever.sh all serve the same purpose, the primary aspect of which is to apply things like environment variables at login. Display managers and [login] shells source these things in a predictable precedence order so that environment variables are correctly inherited by children of GUI environment processes and login shells. Login shells? Well yeah, the point of a login shell is that it invokes login-related tasks like setting environment variables from a profile. That's intentionally separate from the behavior of interactive shells because the environments of interactive shells may have been modified intentionally and shouldn't be "reset" to the values applied at login. edit: also .inputrc is the readline configuration file for things like shortcut keys in all programs which use readline (not just bash) and .bashrc is for customizations specific to interactive shells
  - acqq 7y ago
    You see I’ve read this kind of information in exactly the words you use more than once and I still can’t summarize in one sentence where should one put his variables for things to “just work.” Locally for one user. Provided I just don’t know and don’t even care what the differences between the login and interactive shells are and that I just run the whatever terminal it is default from the GUI menu (whichever GUI it is). And your explanation what the differences are is for me still circular, exactly like in the man pages: login shell is the one which invokes login-related tasks, and I should care about the difference from the interactive shells. I still have no idea what that even means, it is what exactly happens when? Anybody knows some sane explanation of these? I admit I never tried to find it, as I tried to read the man pages, didn't find anything reasonable, but knew that it doesn't matter to me. I just want the darn variables to exists whenever I need them. I don't care about the differences. One single place is enough. But now that you say that you "do understand these mechanisms without evicting too much from" your "brain cache" I'd really like to learn everything about the differences. Specifically, when is one invoked and when another for the user "acqq", let's say, on a default Ubuntu system, and on a default Red Hat system? Are really more different user shells invoked in different forms for a single user, on a single machine, between the booting of the machine, logging in (in GUI) and then starting a few times the terminal with shell inside? When is invoked and which is invoked when? And why shouldn't be a single place for the variables I want to define? No idea, but I would be grateful to read about it now. Thanks in advance.
__del__ 7y ago
The general way to set an environment variable is in /etc/profile or ~/.{bash_,,z}profile. PAM uses /etc/environment, and systemd would prefer to have you set up default environment variables in /etc/systemd/system.conf. You can even pass them directly to Linux from your bootloader (unrecognized arguments on the kernel command line in the form foo=bar become environment variables), but the profiles are the generally accepted way of doing it.
- acqq 7y ago
  It is a joke? If I want to set some variable to be present for a single user (me) I surely don't want to ever touch /etc/profile or /etc/systemd/system.conf (and I have no idea what /etc/environment is supposed to be). And even less want to change something in a bootloader. The things are surely configurable in my user home directory.

frereubu 7y ago

I see where you're coming from, but I think it's the attitude of the developer that's more important. I've learned a good deal of Bash from places like SO, but I've always tried to learn why the command is like that, and I've found other sources more useful than man. If someone is the kind of developer who blindly copies and pastes chunks of code from SO then there are bigger problems than not using man.