I've added a counter (of successful commands in a row) to my bashrc. I've seen it as high as 120.
function promptCommand()
{
LAST_STATUS=$?
# Set title of window to dir, then add new line to prompt.
PS1='\[\e]0;\w\a\]\n'
if [ $LAST_STATUS -eq 0 ]; then
((successes++))
PS1+='\[\033[1;32m\][$successes]'
else
successes=0
PS1+='\[\033[1;31m\][0 $LAST_STATUS]'
fi
PS1+='\[\033[0;32m\] '
PS1+='\w $(date +%H:%M) \$ \[\033[0m\]'
}
lastStatus=0
successes=-1
PROMPT_COMMAND="promptCommand"
I like this joke, it kind of reminds me of the difference between `find_by_id` and `find` in ruby on rails.
In the former, if a result can't be found it will return `nil` but in the latter it expects the record to exist and so will raise an exception if it can't be found.
that sounds so backwards. `find_by_id` is a lookup, not a search; it seems implied to me that the ID should exist and if it doesn't that's an exception. Whereas `find` is a search and it's not atypical for search results to be empty.
Since I think rails 4 or earlier it's preferred to use `find_by(id: 4)`, but could instead be `find_by(email: "email@example.com")`, or even `find_by(first_name: "Franky', last_name: "Tomato")`.
IMO returning nil instead of an exception for the above is practical for me. Much easier to work with.
Having `find(4)` raising an exception is because you'll typical use it in your member actions for a controller where it's reasonable to want an exception if something can't be found.
It's just Rails being Rails (practical sometimes at the expense of possible interpretation of correctness). You do have to retain stuff like this in your head, but it becomes habit pretty quickly.
I've never seen `find!`. If that's a thing, then I have no idea why.
I've have found `find_by!` useful though. Say you want to raise an exception with `find_by!(email: "asd@asd.com")` or `find_by!(slug: "parameterized-string")` etc.
Negative result is still a result. I sometimes use `grep -r` to check whether "does this set of files contain this particular string?" and "no" is a useful answer :)
> The reaction from the OS is actually rather underwhelming.
Somehow related, a coworker at a previous place unmounted some disks on an old AIX production box. It took him a solid minute to realise he had mistakenly unmounted / due to a typo (yes it was possible) as old processes with already opened files were happily serving stuff and only new attempts at opening files were beginning to produce errors.
Also, a similar interactive mishap in the heat of the action:
somebox:~$ rm * .o
rm: .o: No such file or directory
somebox:~$ # ...
somebox:~$ # *stares a prompt*
somebox:~$ # Wait, what? _Please_ tell me those C files were versioned! (The answer was, obviously, "no")
Within the first year or so of having installed Linux (mid-90's), I made the mistake of accidentally deleting /etc (wrote a script to tidy /tmp at boot, but it hadn't cd'd correctly).
That was possibly the best unix/linux learning experience of my life. Rebuilding /etc sufficient to rescue my files I cared about before a reinstall. Rescue CDs weren't really a thing, USB was a new thing at the time, and I was on dial-up.
A few months back I was wiping some old drives using a USB->SATA adapter plugged into an old Linux machine I keep around for experimenting on random things. Mostly because I could just leave it to run for however long it took. There were two drives in the machine, sda and sdb. So the drive came up as sdc.
So then I typed:
$ shred -n1 -v /dev/sda
Took me about 4 seconds to realize what I did before hitting Ctrl-C.
Then, I sighed. Considered whether I could save anything. Realized there wasn't anything on there worth saving, and reinstalled. :)
I'm usually much more cautious than that and I'm thankful it happened on a dumb test machine at home and not something important, but it was still a bummer and my first real sysadmin-type screw up. Mistakes happen, though. Even Linus once dialed his hard drive [0].
Shortly after I started using Fedora as my daily driver I was attempting to dd if=/dev/zero the MBR and partition table off a USB disk sdb and accidentally wiped the one off of sda instead.
As luck would have it, I had the output of fdisk -l /dev/sda in my terminal scrollback buffer and was able to recreate the partition table with no damage done.
Waay back in the day I was using crusty old shared Sun3 workstations. The keyboard was really sticky because, well, some students are pigs. I developed the habit of SLAMMING the Enter key on each command, until one day I was deleting backup files (rm *~) and my fingers grazed the delete button before striking Enter...
> The keyboard was really sticky because, well, some students are pigs.
I work at a technological youth centre, teaching kids cool things to do with computers, programming, music and whatnot. All the hardware we get is donated from businesses, schools, etc. (because volunteers / zero-budget).
And this is just ... ahh. I usually cope by trying not to notice and focus on the screen instead. Sometimes though the ick overwhelms and I fail, curse and go on a hunt for a slightly less gross keyboard. And wash my hands after--though I kind of wonder if that even really makes a difference in this particular scenario (except for the idea of it), afaik the main benefit of washing your hands (in these situations, not if you're a surgeon or a cook etc) is some kind of herd-immunity deal isn't it? And given the keyboards stay dirty, and the kids continue to work on them hands-to-keyboard-to-nose-to-mouse-to-mouth-to-keyboard-to-everything-repeat (esp. the younger ones).
You know what would be really nice? Dishwasher-safe keyboards.
And yeah (before anyone replies with a link), I'm sure those exist already. Except that many of the places that need them don't budget for new (or specialty) keyboards but rely on donated used ones. But it would be really nice to have :) :)
The solution implemented roughly a year into my position was to liberally spread cans of wet-cleaning-wipes. It was such as obvious solution and it helped tremendously.
Alternative keyboards weren't an option in those Sun 3 days, but I've brought my own chair, keyboard, and mouse to work for decades now.
Years ago, I forget how, I managed to wipe the partition table of a DOS PC. I ended up reconstructing it by hand using MS-DOS Debug and a copy of Peter Norton's book.
Another fun one: "killall" on Linux kills processes with names matching a string. "killall" on Solaris reboots the machine ...
Nope, real life occurrence. A variant includes mashing Enter on a valid rm line but on AZERTY keyboards that may mean fat fingering the nearby asterisk key.
On Illumos rm -rf / does nothing. POSIX says that removing / has undefined behavior, so the obviously smart (useful, user-friendly, GOOD) thing to do is to do nothing, as that fits "undefined behavior".
That's quite funny... but ultimately futile. It doesn't say what happens if you say "DROP TABLE xyz<ENTER>WHERE...ohshit". (The <ENTER> bit is because you're used to doing that in your preferred SQL-DB editor.)
One should NEVER do anything non-scripted on a production system. ALWAYS enter it into a file and then do the "run-sql-from-a-file" command.
EDIT: Yes, I also realize that "rm -rf /" can theoretically happen if you have a bad variable substitution, but you MUST turn on the flags that cause your shell to error out instead of just substituting the empty string.
Protecting against every damned footgun is not possible. But some footguns blow users' feet off so often (this one because shell scripting is so tricky and dangerous) that it's est to do something about it.
Indeed not, but just having the extra step of "write this into a file" (and perhaps have someone look it over) catches most of those really bad mistakes.
It's really about NOT getting into the habit of "just fix it in production". That way lies madness.
If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands.
No, doesn’t work like that, meaning it should actually delete everything. The shell is expanding /* to the list of paths, not rm, and /* does not expand to / at all.
Try adding “echo “ in front of the rm command line to see how it expands. (That, by the way, is often a good idea.)
That also reminds me of something similar, where a random offset in /dev/mem is clobbered. What potentially makes it more amusing is that it would probably just crash your machine, rather than completely destroy it.
"Update 2015-04-18 -- I suppose I should finally clear this up: The autocorrect functionality I originally described here was a feature of the first Linux systems I ever used, so I assumed it was how every Linux system worked by default. Since then I've come to understand that it's a completely optional extra doodad."
There's the cdspell shopt: "If set, minor errors in the spelling of a directory component in a cd command will be corrected. The errors checked for are transposed characters, a missing character, and a character too many. If a correction is found, the corrected path is printed, and the command proceeds." (https://www.gnu.org/software/bash/manual/html_node/The-Shopt...)
I knew a guy who aliased all permutations of 'make' (maek, mkae, amke...) to 'make', so he just hammer the keys at once and be sure the thing would run.
I've had to do this with grep, gerp gpre gper. I've determined that I'm just constitutionally incapable of typing that word more than 2 in 3 times, and I've learned to cope with my disability.
Just have to mention, since I recognize the domain, that Sam Hughes has some excellent science fiction freely available in a serialized form here as well. Well worth investigating.
I didn't get any such request in chrome on android. Then again, that's the kind of site with the kind of subject matter to randomly request access every nth page just for the reaction it evokes.
This is funny. I think I’ll stick with “thefuck” [1] though.
It would make a good prank to set up on someone that left their machine unlocked. Not sure if it’s more funny than changing their background to goatse.
In all seriousness, what if it's a machine that no one should ever really be running commands on? This could be an effective, albeit naive, way to discourage undesirables in the system.
I was in a sys admin class with a friend of mine and we both had access to the same machine to work on our assignments. I aliased each and every common command to `sl -f` on my friend's user as a prank (he never actually logged in as it turns out). However, my instructor, while projecting his screen to 150+ students (and recording) picked our box and my friend's user to use as an example. My instructor was flabbergasted for a few minutes and the class got a kick out of flying trains. :D
My personal nemesis is "mroe". Also aliased. My wife, who drafts a lot of legal contracts, has a problem with "doe snot", which the spelling checker is more than happy with.
A friend of mine aliased `git status` `git statsu`; I, being lazier, chose `git st`. Any time saved I lost by not copying his other alias, `c = commit -amSTUFF`...
for me it's "date" and "data" since I type both of those quite a lot (I don't have a clock on my desktop, I just use date when I need to know the time, I find a clock distracting because I get that "well it's 27 minutes til that meeting, never getting in the the zone in that time, better check HN" thing).
It would be nice for someone to develop a suicide-g++. Whenever you compile a program that results in Undefined Behavior, the execution of it will wipe your disk.
bash corrects your spelling?? Is this a cute way of saying "I made a typo that turned out to be a legit command" or is there some DWIM I don't know about (and thankfully don't have enabled)?
One idea I like is randomly flipping a bit on the root partition every day or so. You'll have to take an incredibly long time to find the problem, of which there will be one eventually.
Haha, how can it do that out of interest, if you're not root? (As aren't the top level directories in / owned by root?, or does it work anyway, if rm can recurse down? deleting files from the current user)
In the video he says that you need to be root when you make the typo. But since you have to be root when you install the package, you could plant a suid binary or even leave a service running as root that deletes all your files later.
As far as I know, it can recurse down and get to more files than you want.
The alternative is that the last time I ran that command, it was actually on an account with write rights to the root dir.
1) death by accident (or rm -rf'ing) is not suicide
2) has the bar been lowered that much now? a simple bash configuration makes a new O/S or distribution?
