What does the 'rc' in `.bashrc`, etc. mean?

https://superuser.com/questions/173165/what-does-the-rc-in-bashrc-etc-mean

by janvdberg • 6 years ago

297 61 6 years ago

readwind• 6 years ago

It means 'run commands,' I googled it for you.

Just google for "rc unix meaning", as I did. Have to acknowledge I didn't know it either. But now we all know. Good question.

Edit: more info here, https://en.wikipedia.org/wiki/Run_commands .

pcr910303• 6 years ago

Just google for "rc unix meaning", as I did.

FYI, the link mentions not only 'run commands' but also 'resource control', 'run control', and 'runtime configuration'.

Instead of bashing a stranger to google, reading the link might be more productive.

DoofusOfDeath• 6 years ago

It's plausible that the GP was trying to teach someone the basics of how to research this thing.

KineticLensman• 6 years ago

I googled it for you

I checked in my copy of the jargon file (which I downloaded in August 2001) and got:

rc file /R-C fi:l/ n.

[Unix: from `runcom files' on the CTSS system 1962-63, via the startup script /etc/rc] Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up. See also dot file, profile (sense 1)

loeg• 6 years ago

Still referred to as "runcom" by FreeBSD init (pid 1), for example, in reference to the /etc/rc program (pid 2):

https://github.com/freebsd/freebsd/blob/master/sbin/init/ini...

rumanator• 6 years ago

Still referred to as "runcom" by FreeBSD init

Not to be confused with zombocom.

kadal• 6 years ago

Welcome to you who have come to zombocom!

konart• 6 years ago

Never bothered to google, but always assumed it was something like 'respective config' :D

fooblat• 6 years ago

The Jargon File is still a great resource for this kind of search and if you like these background stories like me you might also enjoy reading all of it.

[Unix: from `runcom files' on the CTSS system 1962-63, via the startup script /etc/rc] Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up. See also dot file, profile (sense 1).

0. https://www.eps.mcgill.ca/jargon/jargon.html#rc%20file

teddyh• 6 years ago

The canonical location of that link is:

http://www.catb.org/~esr/jargon/html/R/rc-file.html

fao_2• 6 years ago

The canonical location of the jargon file is at jargon-file.org, which contains not just ESR's jargon-file, but also pre-ESR versions. Apparently he ripped a lot out that represented LISP and ITS culture, and spun some of the political aspects of it to conform more to his taste.

"rc-file" does not seem to be present pre-ESR, however: https://jargon-file.org/archive/jargon-1.0.3.dos.txt

mariocesar• 6 years ago

I was always thinking it was mean something around Resource or Configuration ... For what it means it's just off how is used now, for example, the common `.prettierc` is a JSON configuration object, just that. I feel like culturally the `rc` suffix means Configuration.

Maybe unlikely but maybe still, this is one of those things how language evolves where a word/suffix has an original meaning that is lost in the practical use day today.

Well, at least! I had no idea the meaning behind it, and it amazes me how I never think it about it.

rat99882• 6 years ago

In .prettierc only c is the suffix actually. `rc` has never meant configuration for me. I actually always wondered about what it meant too.

hombre_fatal3• 6 years ago

They meant .prettierrc: https://prettier.io/docs/en/configuration.html

sedatk2• 6 years ago

I thought of the same.

neetfreek• 6 years ago

Tangentially related - but for those interested in finding out the ideas behind various Debian package names: https://wiki.debian.org/WhyTheName

migueloller• 6 years ago

“Run Commands”. These text files contain commands that are to be run during startup, like when starting a new bash session, for example.

john-radio• 6 years ago

OP isn't asking the question; they shared a hyperlink to a StackOverflow conversation that answers the question.

FPGAhacker• 6 years ago

My first introduction to .___rc files was with irix back in college. Somehow I got it into my head that it stood for Resource Chest. I probably just made it up.

notatoad• 6 years ago

I've never heard that before, but I like it. and next time somebody is asking this question, I'll probably remember it and repeat it as if it were fact.

sedatk2• 6 years ago

I also had thought of “resource configuration”.

frereubu• 6 years ago

Previous thread with 126 comments on the Wikipedia article about Run Commands: https://news.ycombinator.com/item?id=20853214

The comments are more interesting than the Wikipedia article...

donarb• 6 years ago

For me, the hard part is remembering if .bashrc is supposed to source .bash_profile or vice versa.

goblin89• 6 years ago

My rule of thumb: shell-independent commands go to .profile, those ran at boot time go to .bash_profile (or shell-appropriate) which then sources .profile, those ran each time you open a new shell go to .bashrc (or shell-appropriate).

AareyBaba• 6 years ago

OSX is an exception. OSX runs a login shell for each new terminal window and executes .bash_profile. # http://www.joshstaiger.org/archives/2005/07/bash_profile_vs....

rurban• 6 years ago

Nope. Shell specifics go into the name or extension. like .bash_profile over .profile. or /etc/.../bla{.csh,.bash,.sh}

.profile is only for login sessions, .shrc is sourced on every shell fork, about 1000x more than .profile.

earthboundkid3• 6 years ago

The state machines for what calls what when is so insane and stupid. Just have one file and set env vars for “is a TTY” “is SSH” etc. It’s crazy that they kept making the calling conventions so complicated instead of thinking about the existence of “if statements”.

acdha2• 6 years ago

After using bash since ~1993 I switched cold-turkey to fish around a year ago. In retrospect, one of the most enjoyable aspects has been how little I need to customize since it does the right thing out of the box and I can just free up all of the brain capacity I used to spend on the intricacies of the best way to configure bash.

JdeBP2• 6 years ago

Actually, they are fairly simple. A case in point is the basic Korn shell behaviour.

* There are two scripts run by a login shell, $HOME/.profile and /etc/profile .

* These scripts set up environment variables and other things (e.g. umask) to be inherited by the whole login session.

* They, specifically, optionally set an ENV variable whose value names a third script that is run by every interactive shell, including the interactive login shell.

That's exactly three scripts: one for the system administrator and another one for the user to set up login-session-wide stuff, and one for the user to set up this-interactive-shell stuff (such as the shell variables for fancy prompts, completion settings, command-line editing stuff, useful interactive shell aliases, and whatnot). They are always in the same order. And they are simply based upon two things: whether the shell is a login shell, and whether the shell is an interactive shell.

The C shell mechanism is similarly simple, on its own.

The complexity mainly comes from the fact that the Bourne Again shell and the Z shell, amongst others, have multiple mechanisms mixed together and extensions. They look for scripts that are specifically in their own shell languages rather than potentially shared with other shells; .zprofile and .bash_profile instead/ahead of .profile , for example. They have extra scripts that mirror the C shell way of doing things; .zlogin, .zlogout, .bash_login, .bash_logout, .bashrc, and .zshrc, for example. They have idiosyncratic and non-strictly-standard ways of deciding what constitutes an interactive shell. They have mechanisms for disabling the extensions, and ways to come up in alternative not-strictly-conformant sh-compatible modes.

marcosdumay• 6 years ago

I just symlink one into the other.

westurner• 6 years ago

  info bash -n "Bash Startup Files"

https://www.gnu.org/software/bash/manual/html_node/Bash-Star...

throwaway2048• 6 years ago

I just symlink the two, the distinction is mostly useless and annoying, because random things will invoke login shells (or not) and even if behavior was consistent, its really not that useful to begin with.

Optimal_Persona• 6 years ago

Funny, I came across this very same question/similar answer yesterday in "Build Awesome Command-Line Applications in Ruby 2" by David Copeland (Pragmatic Programming, 2013): [0]

"The .rc Suffix (Origin Story)

Most UNIX commands use the suffix rc for the name of configuration files. According to Wikipedia, this extension isn’t an acronym for “resource configuration” or “runtime configuration” but comes from a command called RUNCOM.

RUNCOM was created by Louis Pouzin for the Compatible Time-Sharing System (CTSS), which was one of the first time-sharing operating systems. RUNCOM was used to execute a series of commands in succession—a precursor to what we now call a shell script.

He is even credited with coining the term shell, as he describes in a post on the Internet from 2000 on the origins of the shell:

'After having written dozens of commands for CTSS, I reached the stage where I felt that commands should be usable as building blocks for writing more commands, just like subroutine libraries. Hence, I wrote “RUNCOM”, a sort of shell driving the execution of command scripts, with argument substitution. The tool became instantly most popular [sic], as it became possible to go home in the evening while leaving behind long runcoms executing overnight.

Without being invited on the subject, I wrote a paper explaining how the Multics command language could be designed with [the] objective [of using commands somehow like a programming language]. And I coined the word “shell” to name it.'

Although RUNCOM (and CTSS) has long-been retired from regular use, its legacy lives on both as the name for user-specific configuration files and as the basis for the UNIX start-up scripts, typically located in /etc/rc.d."

[0] https://pragprog.com/book/dccar2/build-awesome-command-line-...

unused0• 6 years ago

But oddly, in Multics they became "ec" (execute command maybe?).

r 13:41 0.055 7

ls >sc1>system_start_up.ec

Segments = 1, Lengths = 2.

r w 2 system_start_up.ec

emmanueloga_• 6 years ago

I go back and forth on my feeling about terseness, abbreviations and 3 letter acronyms. 3LA are almost always annoying, specially since they overlap so much.

In source code sometimes a longer name really helps, but then some people take it to the extreme and make everything look pretty ugly and tedious to work with.

In this case, I guess it would not had been that bad to name the files `.bash.runcommands`. `.bourne-again-shell.run-commands`: maybe too much :-)

torben-friis• 6 years ago

I think the issue is that abreviations and acronyms are mostly ok only when its meaning is so widespread it's unmistakable - but then again, an acronym never reaches that state at birth.

What does the 'rc' in `.bashrc`, etc. mean?

Related Stories