Hacker News new | past | comments | ask | show | jobs | submit login
Run Commands, the 'rc' in '.bashrc' (wikipedia.org)
620 points by rspivak 19 days ago | hide | past | web | favorite | 125 comments

The history of /usr and /home are pretty amusing too:

'When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).' - http://lists.busybox.net/pipermail/busybox/2010-December/074...

I found it funny that random decisions from 60s, 70s, 80s still have repercussions on how we use computers today, because backwards compatibility beats cleanliness every time.

Be right back, solving some Windows backslash and CRLF issues.

It’s not just software. A mechanical engineer once explained to me that the size of the Space Shuttle was influenced by the width of a Roman road, which was influenced by the width of two horses walking side-by-side.

It's a fun myth but it's not true. The SRBs for the Space Shuttle were designed to satisfy their mission criteria. While any similarity between US rail widths today and Roman roads is due more to happenstance than a direct result.


> What's True: The standard U.S. railroad gauge is similar in width to the wheel spacing of Roman chariots.

> What's False: That similarity is based much more on coincidence and inherent physical limitations than a direct line of imitation.

The width of chariots/wagons/car/trains doesn't vary all that much, not compared to stuff like sailing ships.

But the Space Shuttle SRBs have a considerably larger diameter (3.7m compared to 1.435m rails) so it's more likely due to civil engineering standards: you can only transport something so big until you need to take down power lines and cut down trees.

The Falcon 9 has the same diameter and it was explicitly chosen because it's the maximum transportable by road.

Um, nope. The choice of railroad gauge was a historical artifact: in the beginning, everyone had a different gauge, then we had like 15 gauge standards and "standards", and one of them eventually prevailed (through British administrative fiat). The choice was not due to an inherent superiority of this particular gauge, but due to a campaign by George Stephenson. From there, it was mostly network effect: popularity breeds popularity.

Gauge is, most of all, a tradeoff between construction costs (tunnels, bridges, cuttings, oh my! Every additional inch of the gauge gets real expensive in Actual Terrain; ditto for train stations: narrow gauge can fit many more tracks next to each other), and between operating costs (wider gauge cars can be wider _and_ higher, as they're inherently more stable; thus, more cargo on same number of cars).

( ObXkcd: https://xkcd.com/927/ )

On another note, human intelligence is limited by the width of the birth canal.

Interestingly, some distros have undone/are undoing the usr split, fedora around 2012 and Debian still ongoing, see https://wiki.debian.org/UsrMerge and its associated links

On NixOS:

    % find /bin /usr
/usr and /bin are only there to provide sh and env for compatibility with shell scripts.

If nothing is in /bin or /usr/bin, where do proggies live? And what does your path look like?

In the Nix store (/nix):

    % which cp
Each package has its own path in the nix store:

    % readlink $(which cp)
The current system and previous systems also live in the store (Nix has atomic upgrades/rollbacks). Each system can be seen as a package with symlinks to binaries, man pages, etc. in the store. More information about the motivation behind Nix's approach can be found in Nix Pill 1:


In NixOS, they are probably under some directory with a random name.

This is the OS where each binary runs with a different path and library path, with only the programs it needs (on the versions it needs) linked there.

Yes, the UsrMove project. It is great leadership to go to the trouble to fix things like this. https://fedoraproject.org/wiki/Features/UsrMove

Why are they going from /bin to /usr/bin instead of /usr/bin to /bin ? I would have thought they could flatten things out.

A goal of Fedora was to have a "snapshottable" /usr that includes as much as possible (all?) of the generic OS files. That is, multiple machines running the same OS can have a shared /usr, and everything machine-specific in the other dirs.

See https://fedoraproject.org/wiki/Features/UsrMove#Why_don.E2.8...

> Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /.

> Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories.


Weird edge cases where /usr is mounted, such as a read only network drive

Character encodings using shift/unshift bytes were born out of serial transmission.

... Also check out those ^Zs at EOF, will ya.

Because there's this "never touch a running system" fear, deeply rooted in our industry.

The whole "move fast and break things" is a big lie, because you know that in that way, the system works, newer changes will break countless systems/scripts/etc

Also because doing the same thing over and over again "[because X for X in (consistency, security, esthetics, whatchamacallit)]" grows old fast - and by the time it's been fixed and running again, X is no longer there, or it's been totallty twisted out of the intended shape.

You are both correct.

There is a risk of change.

There is a risk of stasis.

I think the latter is a much lesser risk, assuming the "works" in "if it works" is indeed correct. After all, sure, /usr has a funny history, but in practice it doesn't really bother anyone.

That could be the case. One example of the cost of stasis: the / vs /usr requirement in the FHS might stop or complicate future technical possibilities that use the filesystem (packaging systems, distros, copy on write snapshots etc) from being possible. Sure it's a low cost in this instance, but there's always a cost.

It's one more thing people have to learn. For that reason it imposes an ongoing cost.

The CS department at UT Austin added a /lusr mount for locally-compiled software like the GNU tools; putting /lusr/bin at the start of your path made all of the various systems behave more or less alike.

Pronounced "loser".

/home came much later. I don't think they ever had it at bell labs.

usr stands for Unix System Resources, not user.

That's a backronym. It was originally short for user.


See page 9.

More interestingly, I only recently learned that you can add a ~/.ssh/rc to run commands on every ssh login. Are there other common useful rc locations people are aware of?

Can anyone give an example of a command I'd want to run on every .ssh login, but not put into my .zshrc/.bashrc on that machine?

As an example: I'd love to run `set -o vi` on every ec2-user login, but the machines tend to be ephemeral and this command might not be wanted by other users, so I don't add it to /etc/profile or /etc/bashrc.

Why wouldn't you put that in ~/.bashrc ?

The ec2-user is shared by all users who might login; our EC2 hosts usually only last a few minutes/hours and are only accessed during debugging or extraordinary circumstances.

The .ssh/rc file goes on the server though, so you’d still have that problem.

What if you don't have a home directory on an ephemeral server?

Then you won’t have anywhere to store ~/.ssh/rc, and the version you’d put in /etc would still unfortunately apply to all users.

Your ssh rc is stored locally, to be executed on remote servers, right? Locally you have a home dir, but you don't on the remote.

No, it lives on the server.

allows you to use vi on the command line for anyone else who was wondering.

okay? If i'm wrong, what's it for?

It could be worded better. It allows you to use vi style keybindings when editing a line in bash. By default bash uses emacs style keybindings. It doesn't actually use vi.


If you run a terminal multiplexer like byobu you may want to run it only for the ssh connection, not for every sub-shell (otherwise you may get a warning about running a multiplexer inside another multiplexer session).

`w` on multi-user machines that you're logging into to debug, so you can see who's on it and when they were last active.

You can automatically (re)start tmux so your sessions survive losing a connection.

You might want to curl the weather on your login with https://github.com/chubin/wttr.in I do this on my RPi

Starting a multiplexer

Notifications from sysadmin to user, reminders, and that sort of thing.

That's what /etc/motd was intended for

motd is not a per-user dynamic output though unless you put together some interesting hacks.

Do you add that on your system, and it executes the commands on all the servers you connect to?

Or do you add it to the server and they only run when you login to that server?

Looks like it executes the commands only on the server where ~/.ssh/rc or /etc/ssh/sshrc exists.

> ~/.ssh/rc

> Commands in this file are executed by ssh when the user logs in, just before the user's shell (or command) is started. See the sshd(8) manual page for more information.

You add it to the remote system.

I use it for updating a symlink in a known location to point to SSH_AUTH_SOCK. I then get tmux sessions set up to look in that location. Effectively, each time I ssh in, I fix all the ssh forwarding in active sessions (this is on local dev vagrant machines).

Whoa! Thanks for that tip, that’s an incredibly useful tip.

So 'run commands' is the historically correct interpretation.

For me, I've heard it explained as 'run configuration' many years ago and that is the explanation that stuck because rc is in essence used for config files no matter if they run commands or not. Others have found different expansions, which are probably equally obvious for them. The ones I stumbled upon by a quick search [1,2,3,4]:

    run commands

    run control

    run configuration

    runtime configuration

    resource control
Maybe there are more.

[1] https://unix.stackexchange.com/questions/3467/what-does-rc-i...

[2] https://superuser.com/questions/144339/vimrc-screenrc-bashrc...

[3] https://askubuntu.com/questions/23482/what-does-rc-in-bashrc...

[4] http://www.catb.org/~esr/writings/taoup/html/ch10s03.html

Certainly the other expansions are backronyms, invented by people wondering what the "rc" stands for.

Ditto here - I've heard it referred to as runtime configuration for decades (even when I worked at SUN writing drivers and interfaces for SunOS 4 and 5).

There's a little bit of history in there too though, which I appreciated. The fact that the title of the linked article on Wikipedia is "Run Commands" could make the HN title seem clickbaity, but I would never have clicked on something that just said "Run Commands", and now I know something new.

Wikipedia could also be safely considered as "not a clickbait site".

Oh yeah? This Wikipedia page is pure clickbait: https://en.wikipedia.org/wiki/Clickbait

Comes with a pretty amazing example as well: "7 Clickbait Advertisements You Won't Believe".

Yes but without the context it's a bit hard to know what's it talking about

Yeah but just look at this article title!


The purple prose!

Meaning the prose is literally purple, because you've obsessively clicked all the links?

> The fact that the title of the linked article on Wikipedia is "Run Commands" could make the HN title seem clickbaity, but I would never have clicked on something that just said "Run Commands" [...]

Wouldn't "the RC in .bashrc stands for Run Command" be alright?

Perhaps, but the interesting part for me was the historical background (small as it was). What I suppose I'm saying is that in this particular instance I didn't mind that I took the bait. A bit better than "Unix sysadmins don't want you to know this one weird trick!" or "You'll never believe what the RC in .bashrc stands for!" at least.

>Perhaps, but the interesting part for me was the historical background (small as it was). What I suppose I'm saying is that in this particular instance I didn't mind that I took the bait. A bit better than "Unix sysadmins don't want you to know this one weird trick!" or "You'll never believe what the RC in .bashrc stands for!" at least.

You're literally saying you're okay with clickbait removing four words and an exclamation point.

OK, now can somebody explain to me the difference between .bashrc and .bash_profile?

They're part of a complicated initialization process that can only be answered with this beautiful diagram.[1][2]

[1]: https://blog.flowblok.id.au/static/images/shell-startup-actu...

[2]: https://blog.flowblok.id.au/2013-02/shell-startup-scripts.ht...

Which gets it apparently wrong, as bash executes the *profile stuff on interactive login shells also.

Oh, hey, that's great. Thanks for sharing.

Profile is for login shells (thus executed once when logging in at the terminal or over SSH). The rc file is for interactive non-login shells (thus executed once each time you open a new e.g. xterm window).

But some systems treat all terminal emulator windows as login shells by default (e.g MacOS), though you can change that behavior.

Interactive shells can also be login shells, and they run bashrc too (don't they?)

Wait... is this the reason why you see profiles that load bashrc?

Mostly running a shell script doesn't necessarily need to have all your aliases included, for one of many possible examples, but it conveniently doesn't really hurt things either. Making one setting the default is a way to promote "sameness" for those who aren't about to go about adapting different use cases.

But for "power users," the ability to alter the experience depending on context is there awaiting your specifics.

You'll get answers having to do with "login shell", but none of them will really hit the spot.

OK, actually this is correct and what the difference between the two files is (profile is loaded by a login shell, bashrc is loaded by an interactive shell), but can you tell me the real difference between ~/.bash_profile and ~/.profile?

The real answer is, read the entire man page to understand.

From the page .bashrc runs in every shell, so long as it is an interactive shell. Bash can be interactive according to a complex system of connected variables, including $PS1, $-, and the arguments passed into bash itself. I found all of this described fully in the Invocation section of the man page, section on interactive shells.

However, profile is loaded when the shell is a login shell. Which profile? Also from Invocation, continuing on from an explanation of when .bashrc is loaded:

> After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

So, .bash_profile may or may not be loaded, and .profile being loaded or not loaded depends on the existence of those other two files in order.

Your response was lazy but on point. This is the darkest of man page magic, and nobody who hasn't read the manual will know the answer in complete detail. Everyone who has spent any real time in a shell has learned part of this answer.

The reason for that is that .profile was also read by login Bourne and Korne shells, with which bash is supposed to be backward compatible.

So if you only have a .profile, it makes sense to source that. If you have one of the bash-specific ones, then it's up to you whether you want to `source` the common .profile one or not.

The real fun comes when you want to run commands in every shell, whether interactive or not. For example, aliases that you want available when you use shell escapes like ! in vi.

The only way to do that is to have the file's path explicitly in $ENV, or $BASH_ENV of course...

it's in the man page

former is runtime bash environment, latter is when you log in with an interactive shell to run commands, and stuff.

Interestingly, in a `readme.md` that I had to write[1] yesterday, I had to refer to this file, and I used the term "rc file".

I wondered what "rc" actually meant. It's interesting because I found the answer today on HN. So random and unexpected .

Anyway, I wonder whether if I referred to it as the "Run Commands File", would the people recognize what I meant.


1. https://github.com/a2way-com/template-docker-laravel/blob/55...

Spurred me to find out that the ht in .htaccess is Hypertext

I spent the last 20 years thinking it was for “resource” — and now I can’t even remember why I thought that.

I thought that too, for me it's due to Windows resource files having `.rc` extension. how mind works


ESR promulgated that in TAOUP.

Run commands is funny since many modern tools use ...RC files which usually don't include direct commands, but declarative configuration.

I always thought it was 'runtime configuration'.. as opposed to compile-time configuration.

I always thought of it as "remote controlled" even though it makes absolutely zero sense

Interesting. So basically, the "rc" in ".bashrc" has a meaning similar to the "EXEC" in "AUTOEXEC.BAT".

Same as /etc/rc. (From which are obviously derived: /etc/rc.local, /etc/rc.d, etc.)

FreeBSD init(8) still refers to it as "runcom":



Hmm, I thought it was "run control" . . . ;)

I bet we all read the same Eric Raymond book/article.

ESR making things up authoritatively on the spot - no way.

Same here ...

I like how it was termed a fossil when it was added to Unix.

Now we seem to be flooded with them. TTY, terminal, core dump, floppy disk save icon.

Interestingly the Plan 9 shell is called rc, written by Tom Duff (see Duff's Device). This has at times lead to some confusion on my part when working between unix and plan 9. Syntax is similar to bash.

to note the:

    rc in Unix
mentioned by K&R in the article likely refers to '/etc/rc', which was a shell script run by init in research Unix (and still BSD, but not SysV)

see also:

for 'then', and:

for (some of) 'now'.

Ironically, .bashrc is not mentioned specifically at all in the Wikipedia page, whereas .vimrc is.

> It is used for any file that contains startup information for a command.

I thought it stood for "reconnect", now I can't figure out where I got that idea.

I always thought rc files stood for ResourCe... in hindsight I realize how doumb that was.

Not dumb at all; in fact, Win32 resource scripts[1] end with the ".rc" extension

[1]: https://docs.microsoft.com/en-us/windows/win32/menurc/about-...

That's probably because they're named after the RC tool which stands for "resource compiler".

Are there any distros with no interest in backward compatibility?

Somehow I interpreted and pronounced it as [r]esour[c]e

>run commands

In case you didn't want to click the link.

Or read/decode the link URL, ending "wiki/Run_commands".

reminiscent of runcom (Louis Pouzin alpha shell)

Saved my life.

I know that it's a figure of speech, but I'm amused by trying to imagine circumstances where needing to click a HN link could be a life threatening situation.

Well hypothetically each mouse button has a certain finite number of clicks in it before it breaks.

It could be in the future you'd need to click to send some crucial evidence to stop you getting sentenced to death. It could be that this saved click is the difference between the mouse failing or not on that occasion.

Of course the parent clicked send on their comment undoing the OPs good work.

This is all astoundingly improbable, but people buy lottery tickets each week.

>Well hypothetically each mouse button has a certain finite number of clicks in it before it breaks.

Omron switches (most commonly used) are rated from 1M to 20M clicks.

>It could be in the future you'd need to click to send some crucial evidence to stop you getting sentenced to death. It could be that this saved click is the difference between the mouse failing or not on that occasion.

Double click is the most common failure mode. When clicking, the switch hesitates back and forth resulting in two mouse click events generated. This could turn "drag and drop" into "launch program". Will leave the rest for your imagination.

"And thus The Last War begun and ended, in a fiery blaze of thermonuclear detonations, initiated by a faulty $10 mouse, whose left switch has far surpassed its expected rating, before failing at a critical probability junction, along with whole of humanity."

That’s why I buy a new mouse after every 10 clicks. It’s pretty rare for them to fail on the 11th click.

Id expect a 'bathtub' failure curve. I'd suggest getting lightly used mice.

Light use is prime market for lemons. No one is going to sell a good mouse.

HN: come for the obscure unix history, stay for the used-commodity micromarket price analysis!

Have you ever seen the movie "Swordfish"?

Well, maybe "saved me a click", then. :-)

Hovering over the link would have saved you a click, too. :P

I used to think bash RC is for Remote Control.

RC files were remote control files for m. I am pretty sure, I can't be the only one who asssumed that.

Would be my first association as well, from things like RC cars and RC planes. Doesn't really make sense in this context, though (but run commands sounds a little bit of as well; something like configuration commands would've sounded better in my opinion).

Wow, the HN title was the click bait and the article was just an article.

I wish Hacker News had a section called Daily Factoids .. this particular article is really interesting but isn't News.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact