Hacker News Reader

Comment by smegel | Hacker News Reader

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

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.

Could you achieve the same outcome by spreading the logic though the three standard bash dotfiles? Standard names plus no symlinks, i could live with that.

Kind of... That's pretty much what mine had evolved into, a bunch of them sourcing each other and making sure they weren't recursively sourced for when they're used on a different OS/machine, with complex conditionals to re-detect if it was interactive or not and logic to try to not re-run things too often that was only supposed to be run on login... with no certainty that they were really doing what I intended in weird circumstances like `ssh ... command`.

But those wouldn't have been "shareable" or standard either- unless they were all shared as a group. When someone says "here are some lines from my .bash_profile"- they are not implying something by having them in bash_profile and not bashrc. No one in their right mind would think "must be something they only want to run when they log in." Instead, you take those lines and put them into your .bashrc or .profile or whatever you happen to have working well enough. Or, worse, someone says "here's my .bash_profile" and someone new to osx drops it in their home directory and all of a sudden nothing works because bash stopped looking at their .profile that already existed, while someone on linux drops it into their home directory and it looks like it's not doing anything at all.

etc. (: obviously people get it to work, and obviously "madness" was a euphemism, but I was tired of all the ambiguity.

You could also replace each of the dotfiles with a script to source the dispatcher. No redundant logic, and you don't mess with system files in a way that might screw up install scripts, etc. (But unless I'm missing something it doesn't seem like you'd break that much by using symlinks.)

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?

Masochistic geeks are a dime a dozen. Once they've memorized an unintuitive design, there "is no problem."

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.

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.

You would never need to know the difference - because you can always read the man page.

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.

$ man bash | wc 5375 41026 312785

"From the Earth to the Moon" by Jules Verne has 39,985 words

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.

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.

man bash

The INVOCATION part. You find this part by searching for the word "profile".

"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.

Reply on news.ycombinator.com