Good to have snapshots (zfs) that you can go back to after a screw-up.
Just pray that the snapshot restoring program wasn't gone.
Suicide Linux
121–130 of 135 posts
Re: Suicide Linux
#122"You know how sometimes if you mistype a filename in Bash, it corrects your spelling and runs the command anyway?".
No, never, on any system ever.
Re: Suicide Linux
#123I'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…
If you're looking for just mistypes, use status 128.
Re: Suicide Linux
#124Re: Suicide Linux
#125Re: Suicide Linux
#126Earlier quoted context omitted.
If it didn't exist in the first place, then you had no business searching for it. You should have just known not to look. :)
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.
Re: Suicide Linux
#127Earlier quoted context omitted.
rm -rf /* ?
I believe the spec says arguments can be deleted in any order, so it always chooses "current directory” first, which fails, failing the whole command
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.)
Re: Suicide Linux
#128Earlier quoted context omitted.
Man, I hope you don't use grep very often (by default it uses exit code 1 when it doesn't find anything).
>grep Not to mention tar which is just impossible to get right on the first try.
This reminds me about https://www.xkcd.com/1168/
Re: Suicide Linux
#129Earlier quoted context omitted.
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.
Re: Suicide Linux
#130Earlier quoted context omitted.
That's quite funny... but ultimately futile. It doesn't say what happens if you say "DROP TABLE xyz WHERE...ohshit". (The 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 b…
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.