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."
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.
> 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.
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?
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.
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).
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.
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.
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).
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
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).
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).
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.
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.
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...
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
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.
> 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.
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:
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.
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 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).
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.
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.
130 comments
[ 5.1 ms ] story [ 230 ms ] threadIn case you didn't want to click the link.
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.
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.
https://en.wikipedia.org/wiki/List_of_unsolved_deaths
The purple prose!
Wouldn't "the RC in .bashrc stands for Run Command" be alright?
You're literally saying you're okay with clickbait removing four words and an exclamation point.
Or do you add it to the server and they only run when you login to that server?
> ~/.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.
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).
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]:
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
RC files were remote control files for m. I am pretty sure, I can't be the only one who asssumed that.
Now we seem to be flooded with them. TTY, terminal, core dump, floppy disk save icon.
[1]: https://docs.microsoft.com/en-us/windows/win32/menurc/about-...
But some systems treat all terminal emulator windows as login shells by default (e.g MacOS), though you can change that behavior.
Wait... is this the reason why you see profiles that load bashrc?
But for "power users," the ability to alter the experience depending on context is there awaiting your specifics.
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.
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 only way to do that is to have the file's path explicitly in $ENV, or $BASH_ENV of course...
[1]: https://blog.flowblok.id.au/static/images/shell-startup-actu...
[2]: https://blog.flowblok.id.au/2013-02/shell-startup-scripts.ht...
https://docs.microsoft.com/en-us/windows/win32/menurc/about-...
> It is used for any file that contains startup information for a command.
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...
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...
'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...
Be right back, solving some Windows backslash and CRLF issues.
See https://fedoraproject.org/wiki/Features/UsrMove#Why_don.E2.8...
> 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...
https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...
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.
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
There is a risk of change.
There is a risk of stasis.
... Also check out those ^Zs at EOF, will ya.
https://www.snopes.com/fact-check/railroad-gauge-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.
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/ )
Pronounced "loser".
http://bitsavers.trailing-edge.com/pdf/bellLabs/unix/Prelimi...
See page 9.