4 ms·

Solution looking for a problem. Not a particularly good one at that.

by smegel 14y ago

ghshephard 14y ago
If I do a survey of 10 engineers who use Linux, and OS X every day - I'm willing to wager that 9/10 of them wouldn't be able to explain what should be in .bash_profile, .profile, and .bashrc. And I can almost guarantee you they couldn't explain the difference between OS X and Linux. I know I couldn't. I like the solution, actually: - .bashrc_all - always gets executed - .bashrc_scripts - non-interactive bash execution - .bashrc_interactive - duh. - .bashrc_login - motd and friends (when you "login") I'd have no problem remembering that. Why don't you think there is a problem, and, why do you believe this is a poor solution to that (nonexistent) problem?
- smegel 14y ago
  I think most engineers can hack their way to .bashrc even if they don't know the exact differences between those files. And those that can't probably don't need to or can get someone to help them. I just don't see a huge problem out there that needs to be solved. Why don't i like the solution? Well it breaks a well known standard which will confuse others: show me your bash_profile and bashrc...wait what they are the same?? Secondly it invokes the terror of symlinks and the spaghetti mess that often results. Sort of a nice idea in theory but i would not do it in practice.
  - cswetenham 14y ago
    Am I correct in thinking that instead of symlinking .bashrc, etc. to new_bashrc.sh, you could simply have them 'source new_bashrc.sh'? This would also mean you could keep all your dotfiles in a git repository without worrying about the symlinks.
- nodata 14y ago
  You would never need to know the difference - because you can always read the man page.
  - azylman 14y ago
    Just because I "can" do something doesn't mean I "want" to do something or that it's the best way to use my time. That's like saying that we don't need expressive function names in code because we can just refer to the documentation.
  - slyall 14y ago
    $ man bash | wc 5375 41026 312785 "From the Earth to the Moon" by Jules Verne has 39,985 words
    - reidrac 14y ago
      You don't need to read the whole manual. It's hard when you're looking for something very specific, but in this case it's just the FILES section, so I'll try man bash and then /^FILES. It's like saying /etc/services has 11033 lines in it. Well, use grep or search in the document.
  - moe 14y ago
    Which man-page exactly? The fun part about .bashrc, .bash_profile, .profile, /etc/bash*, /etc/profile etc. is that their semantics vary wildly between linux-distros. Not even Ubuntu and Debian agree here. You never quite know where, when and if .bashrc is sourced by the distro-templates. A .bash_profile that unconditionally sources .bashrc will work fine on one distro, on the next you will see it run multiple times, on yet another you run into an infinite recursion. His approach is the correct one and you'll find a similar script in just about any sizable, heterogenous deployment.
    - nodata 14y ago
      man bash The INVOCATION part. You find this part by searching for the word "profile".
- digisign 14y ago
  Masochistic geeks are a dime a dozen. Once they've memorized an unintuitive design, there "is no problem."
forgotusername 14y ago
"Let's replace `cd` with a macro that knows some things about my workflow!". Runs script KABOOM. Oh crap, guess I need to make that macro only run for interactive shells. How do I do that? 2 hours later [expletives deleted]. "I want ssh-agent to start if it isn't running, and only for my login shell. How do I do that?" 2 hours later [expletives deleted] Not so sure about .bashrc_script, but the above two are more than justification enough.
jwecker 14y ago
So I admit it's a 10 minute hack done on my way home on the train, but the issue is real even if you understand the man page. Here's roughly the way these work normally. Starting with "login" bash invocation- which means: * On linux, usually only when you first ssh into a machine or boot up into a terminal- and then _never again_ as you open various terminals or su etc. If you boot into gdm or something like most desktops/laptops do nowdays, you may hardly ever see your local machine invoke bash as a login shell. * On a mac, "login" mode is invoked on pretty much every terminal you open. * The login mode of a shell is _orthogonal_ to the shell being interactive (in theory. In practice, and in the gist, a login-shell is almost always a small subset of interactive shell invocations [or larger subset on mac]). The rules for the login shell invocation are to load: ('/etc/profile' THEN (~/.bash_profile OR ~/.bash_login OR ~/.profile - one and only one, the first one it finds)) (and nothing else) UNLESS bash is invoked as a login shell with the 'sh' name, in which case it does: ('/etc/profile' THEN ~/.profile) IF the shell is NOT a login shell but IS interactive, don't load any of the profile stuff but load ~/.bashrc (ignored if bash is invoked as 'sh') Finally, a shell in posix mode and a shell invoked by a script- i.e., non-interactive, will first load any file specified in the BASH_ENV environment variable and nothing else. On a mac, the default for new home directories is to have a ~/.profile sitting there. Should you unwittingly drop a ~/.bash_profile or ~/.bash_login in there one day, you would find (and many have found) that the ~/.profile suddenly stops working (more likely you suddenly notice your PATH isn't set anymore). Except sometimes, when bash is being invoked as sh, in which case ~/.profile is alive again. And, note that .bashrc isn't loaded at all for a login invocation, even if it is interactive (true the vast majority of the time). On a mac, .bashrc seems useless, then on linux, .bash_profile seems useless. So many on linux end up filling up their .bashrc with the good stuff and then realize that when they log in remotely nothing gets loaded so they troubleshoot, read the manpage, and end up sourcing .bash_profile from their .bashrc. On mac, people tend to do the reverse. Oh, and when you are trying to remember what is what and why you should care-- the manpage is almost 5,000 lines long. AFAIK, it's the only manpage the size of a book. Anyway, I was putting my dotfiles into github and spend a lot of time on OSX and Linux so was merging the two sets. I also have seen (and written) so many rc scripts that liberally mix stuff that is relevant for interactive-mode with stuff that should really only be done at login, etc. That said, it _is_ a 10 minute hack so forks + fixes appreciated.

Solution looking for a problem. Not a particularly good one at that.

by smegel 14y ago

Solution looking for a problem. Not a particularly good one at that.

If I do a survey of 10 engineers who use Linux, and OS X every day - I'm willing to wager that 9/10 of them wouldn't be able to explain what should be in .bash_profile, .profile, and .bashrc. And I can almost guarantee you they couldn't explain the difference between OS X and Linux. I know I couldn't. I like the solution, actually: - .bashrc_all - always gets executed - .bashrc_scripts - non-interactive bash execution - .bashrc_interactive - duh. - .bashrc_login - motd and friends (when you "login") I'd have no problem remembering that. Why don't you think there is a problem, and, why do you believe this is a poor solution to that (nonexistent) problem?

smegel 14y ago
I think most engineers can hack their way to .bashrc even if they don't know the exact differences between those files. And those that can't probably don't need to or can get someone to help them. I just don't see a huge problem out there that needs to be solved. Why don't i like the solution? Well it breaks a well known standard which will confuse others: show me your bash_profile and bashrc...wait what they are the same?? Secondly it invokes the terror of symlinks and the spaghetti mess that often results. Sort of a nice idea in theory but i would not do it in practice.
- cswetenham 14y ago
  Am I correct in thinking that instead of symlinking .bashrc, etc. to new_bashrc.sh, you could simply have them 'source new_bashrc.sh'? This would also mean you could keep all your dotfiles in a git repository without worrying about the symlinks.
nodata 14y ago
You would never need to know the difference - because you can always read the man page.
- azylman 14y ago
  Just because I "can" do something doesn't mean I "want" to do something or that it's the best way to use my time. That's like saying that we don't need expressive function names in code because we can just refer to the documentation.
- slyall 14y ago
  $ man bash | wc 5375 41026 312785 "From the Earth to the Moon" by Jules Verne has 39,985 words
  - reidrac 14y ago
    You don't need to read the whole manual. It's hard when you're looking for something very specific, but in this case it's just the FILES section, so I'll try man bash and then /^FILES. It's like saying /etc/services has 11033 lines in it. Well, use grep or search in the document.
- moe 14y ago
  Which man-page exactly? The fun part about .bashrc, .bash_profile, .profile, /etc/bash*, /etc/profile etc. is that their semantics vary wildly between linux-distros. Not even Ubuntu and Debian agree here. You never quite know where, when and if .bashrc is sourced by the distro-templates. A .bash_profile that unconditionally sources .bashrc will work fine on one distro, on the next you will see it run multiple times, on yet another you run into an infinite recursion. His approach is the correct one and you'll find a similar script in just about any sizable, heterogenous deployment.
  - nodata 14y ago
    man bash The INVOCATION part. You find this part by searching for the word "profile".
digisign 14y ago
Masochistic geeks are a dime a dozen. Once they've memorized an unintuitive design, there "is no problem."

forgotusername 14y ago

"Let's replace `cd` with a macro that knows some things about my workflow!". Runs script KABOOM. Oh crap, guess I need to make that macro only run for interactive shells. How do I do that? 2 hours later [expletives deleted]. "I want ssh-agent to start if it isn't running, and only for my login shell. How do I do that?" 2 hours later [expletives deleted] Not so sure about .bashrc_script, but the above two are more than justification enough.

jwecker 14y ago

So I admit it's a 10 minute hack done on my way home on the train, but the issue is real even if you understand the man page. Here's roughly the way these work normally. Starting with "login" bash invocation- which means: * On linux, usually only when you first ssh into a machine or boot up into a terminal- and then _never again_ as you open various terminals or su etc. If you boot into gdm or something like most desktops/laptops do nowdays, you may hardly ever see your local machine invoke bash as a login shell. * On a mac, "login" mode is invoked on pretty much every terminal you open. * The login mode of a shell is _orthogonal_ to the shell being interactive (in theory. In practice, and in the gist, a login-shell is almost always a small subset of interactive shell invocations [or larger subset on mac]). The rules for the login shell invocation are to load: ('/etc/profile' THEN (~/.bash_profile OR ~/.bash_login OR ~/.profile - one and only one, the first one it finds)) (and nothing else) UNLESS bash is invoked as a login shell with the 'sh' name, in which case it does: ('/etc/profile' THEN ~/.profile) IF the shell is NOT a login shell but IS interactive, don't load any of the profile stuff but load ~/.bashrc (ignored if bash is invoked as 'sh') Finally, a shell in posix mode and a shell invoked by a script- i.e., non-interactive, will first load any file specified in the BASH_ENV environment variable and nothing else. On a mac, the default for new home directories is to have a ~/.profile sitting there. Should you unwittingly drop a ~/.bash_profile or ~/.bash_login in there one day, you would find (and many have found) that the ~/.profile suddenly stops working (more likely you suddenly notice your PATH isn't set anymore). Except sometimes, when bash is being invoked as sh, in which case ~/.profile is alive again. And, note that .bashrc isn't loaded at all for a login invocation, even if it is interactive (true the vast majority of the time). On a mac, .bashrc seems useless, then on linux, .bash_profile seems useless. So many on linux end up filling up their .bashrc with the good stuff and then realize that when they log in remotely nothing gets loaded so they troubleshoot, read the manpage, and end up sourcing .bash_profile from their .bashrc. On mac, people tend to do the reverse. Oh, and when you are trying to remember what is what and why you should care-- the manpage is almost 5,000 lines long. AFAIK, it's the only manpage the size of a book. Anyway, I was putting my dotfiles into github and spend a lot of time on OSX and Linux so was merging the two sets. I also have seen (and written) so many rc scripts that liberally mix stuff that is relevant for interactive-mode with stuff that should really only be done at login, etc. That said, it _is_ a 10 minute hack so forks + fixes appreciated.