Run Commands, the 'rc' in '.bashrc' | Hacker News Reader

Run Commands, the 'rc' in '.bashrc'

en.wikipedia.org

620 pointsrspivak126 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.

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

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

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

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.

https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

Arch too, https://www.archlinux.org/news/binaries-move-to-usrbin-requi...

On NixOS:

    % find /bin /usr
    /bin
    /bin/sh
    /usr
    /usr/bin
    /usr/bin/env

/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
    /run/current-system/sw/bin/cp

Each package has its own path in the nix store:

    % readlink $(which cp)
    /nix/store/l96gc2qb8ysnf5hcq1hp5a3r6x905rf4-coreutils-8.31/bin/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:

https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...

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

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.

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

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

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.

https://www.snopes.com/fact-check/railroad-gauge-chariots/

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

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

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

usr stands for Unix System Resources, not user.

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

http://bitsavers.trailing-edge.com/pdf/bellLabs/unix/Prelimi...

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?

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

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

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 ?

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.

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.

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.

thanks.

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

Starting a multiplexer

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

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.

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

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

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

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

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

Yeah but just look at this article title!

https://en.wikipedia.org/wiki/List_of_unsolved_deaths

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?

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

Except Linux terminal emulators tend to launch a non-login shell (where .bash_profile is not read), and at the same time macOS’ Terminal.app prefers login shells.

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

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

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

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

it's in the man page

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

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

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

https://github.com/freebsd/freebsd/blob/90b1841/sbin/init/in...

https://github.com/freebsd/freebsd/blob/90b1841/sbin/init/pa...

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.

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

Same here ...

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

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

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)