Unix Haters' Club
-
Configuration file '/etc/acpi/powerbtn.sh' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** powerbtn.sh (Y/I/N/O/D/Z) [default=N] ?WHAT?
powerbutton.sh? WHAT? WHY?
WHAT?
-
Just today, one of my friends
rm’ed*.pyinstead of*.pycon his work computer.I’m pretty sure I never accidentally lost a file when using a GUI. I’ve already messed up with
rma few times.
-
But yeah. It amazes me GNU people have yet to include something like rm -s(afe) switch that deletes by moving stuff into /var/deleted or something. And then distributions to quietly start adding
alias rm rm -sinto theirbash.rc-s.
-
But it does exactly what you told it to! It's not the computer's responsibility to help you fix dumb decisions etc etc.
(yes it fucking is, it's like one of the most basic UX rules)
-
I've gotten messages like that even when updating a system immediately after installing it.
I always choose to install the new version because I figure if it's newer it must be better.
-
I appreciate the message. I do. I skipped a few files actually, since it would wreck my config. Arch would just run over it, laughing maniacally.
But..
powerbutton.sh? powerbutton.sh?
-
Just today, one of my friends rm’ed *.py instead of *.pyc on his work computer.
And then he restored his code from source control. Right? Right?!
-
And then he restored his code from source control. Right? Right?!
Given the expletives he produced when talking about this incident, I hightly doubt he had committed all his changes.
-
And then he restored his code from source control. Right? Right?!
He tried to, but accidentally typed
git purge-and-destroy --all-including-remotesinstead of
git reset --hard branch
Filed under: An easy mistake to make, I mean, the keys are right next to each other.
-
Technically the keys are all right next to each other, yes.
-
I figure it's the script that gets called when you press the power button. You know how linux is designed:
if (thing) do {run /etc/scripts/thing.sh}. It's a "clean and simple design" because each script has a single, clear purpose, as the Unix philosophy mandates. Need to change something? Just edit the shell script!3 months later you realize that not everybody wants or knows how to edit shell scripts. So you make the script read an external configuration file. Even easier, just edit the file instead! Plus you can now make a GUI tool that edits those settings for you, for the fucking lusers who can't even bother to use a PROPER text-based interface like god intended.
But that turns out to be not quite flexible enough, so someone makes a different tool to generate the scripts for you, with its own configuration files of course, but backwards compatible with the original ones. And then someone else adds another config file to tell the system what tool to use.
Continue for 20 years until every action has to go through at least 12 different scripts and config files, then discard the whole thing and start again. Unix!
-
I might be confusing things, but I think I saw an XFCE-using distribution somewhere that opened the logout/shutdown window when pressing the power button.
-
I might be confusing things, but I think I saw an XFCE-using distribution somewhere that opened the logout/shutdown window when pressing the power button.
I tried that on my work Xubuntu box and was pleasantly surprised by the result.
-
Reminds me of the time (a good 30 years back) when one of the guys at $MAJOR_GLOBAL_FINANCIAL_INSTITUTION wandered around quietly asking if anyone happened to have a tar archive of Dynix for one of the Balance boxes.
He'd been remotely logged in, as root, on one of1 the live trade feed handlers. Thinking he was logged into one of the test boxes, He'd gone to clean up his build directory before rebuilding.
rm -rvf ./bin… followed by a moment of panic as he saw the contents of the live machine's bin directory scrolling up the screen.
ctrlc
ctrlc
ctrlc
ctrlc
ctrlc
ctrlc
ctrlc… and managed to halt the operation just before it removed /bin/untar. The machine, of course, was still running, and as long as the terminal remained up it would be possible to reinstall the bin directory.
As long as he could find a
tararchive.1 It may, indeed, have been feed handler #1 of one
-
...vaguely reminiscent of Mario Wolczko's post from '86.
-
Interesting. There was a similar one on TDWTF a while back.
-
Preach! I adore WinSCP
-
Feeling bored? More Unix hate is the cure!
I was trolling stack exchange sites, looking for something to answer so I can avoid work while feeling like working, when I came upon an article with a very interesting picture.
Do you guys know why vim uses those godawful mid-keyboard shortcuts to move the cursor instead of arrows? You might think it was some clever plan to keep hands away from mouse or to help speed up blind typing or something. But no. The real reason is that an obscure mid-70-ies terminal system's keyboard happened to have arrow keys placed like this:
Really.
No clever strategy to position the hands properly, no usability concerns.
It's just that someone in the seventies had a keyboard where the little arrow icons happened to be printed over the letters H J K and L.
And people have been blindly using this crappy bindings ever since.
http://www.pastoralin.com/wp-content/uploads/2014/06/Jackie-Chan-Meme-Template.jpg
-
People don't complain about WASD very much. In fact, it's the preferred control scheme for first-person video gaming (or at least it was last time I looked) So why all the HJKL hate? Never played rogue-likes?
Also, the usability concern was that there are keyboards that require modal editing. How would you navigate at all if your arrows play double duty?
Also, that obscure terminal had the layout right. Navigation happens constantly. Keeping the arrows near the home keys is the clever bit.
-
It's weird... the first computer I ever had was a ZX Spectrum. 40 keys to the keyboard, most keys did anything up to quintuple duty (standard keypress, language keyword, symbol, extended symbol, very extended symbol), and the arrow keys were mapped in the same HJKL pattern to 5678 on the keyboard.
Though IIRC you had to press another key to get to that, and it was fairly terrible. To the point where most games that needed 4-way movement actually used QAOP for up/down/left/right.
Later Spectrum models did something even more weird. You had up/down and left/right arrow pairs, either side of the spacebar, though they were dedicated keys.
-
Yukk. I wonder if the ZX users who moved on to the Unix side use Emacs. Now there's a contemptible user interface, where every action requires a chord like playing a guitar.
-
I use nano because both vi and emacs confuse me. And I am not ashamed to admit it.
-
Though IIRC you had to press another key to get to that, and it was fairly terrible. To the point where most games that needed 4-way movement actually used QAOP for up/down/left/right.
It was pretty common to have an external joystick, usually one that followed the Kempston interface.
-
Oh yes, I remember that only too well. And the fun and games when the +3 came out that had its own 9-pin D-type joystick port that was incompatible with all the other platforms that used a 9D socket for their joysticks (but were all basically compatible with each other)
-
People don't complain about WASD very much. In fact, it's the preferred control scheme for first-person video gaming (or at least it was last time I looked) So why all the HJKL hate?
WASD makes sense though. It's the same shape as the arrow keys on PC keyboards, and it's under your left hand (you need the right one for the mouse). IIRC early Call of Duties had ESDF instead, but if you go much further to the right and you'd have to either hold your arms uncomfortably or move the keyboard around to play. Furthermore, it's the standard. All games do it, so you're not surprised when you go play a game and it turns out to work like this.
-
Vim understands arrow keys, also. HJKL isn't mandatory. In fact, like many video games, Vim supports rebinding keys.
So the hating is about a sensible optional extra.
-
So one could rebind HJKL to WASD in Vim?
-
Quite possibly, but you'd have to rebind a lot of other things too. These radical rebindings tend to not work out very well.
-
Then let's rebind WASD to the arrow keys. They should be unused now, right?
-
I would personally really hate having to reach over to the arrow keys to use the standard A (insert after), S (delete char and switch to insert), and D (delete) bindings. W moves the cursor to the next word.
It seems more sensible to me to remap WASD to do navigation and HJKL to do the things I mentioned above. But that's just me.
Also, this would be a fun prank to play on your local vim user.
-
People don't complain about WASD very much. In fact, it's the preferred control scheme for first-person video gaming (or at least it was last time I looked) So why all the HJKL hate? Never played rogue-likes?
Also, the usability concern was that there are keyboards that require modal editing. How would you navigate at all if your arrows play double duty?
Also, that obscure terminal had the layout right. Navigation happens constantly. Keeping the arrows near the home keys is the clever bit.
The point is, no one sat down and figured this is the optimal way to handle navigation so that your fingers are always near everything else and so on. They just copied it the way it was on this forgotten keyboard, and never gave it another thought.
For example, why are all 4 direction keys in the same row? Wouldn't it make sense for up/down to be above/below the other keys? Oh, but it was probably easier for some engineer to make a straight conducting line in mid 70-ies, so that's what we have.
-
this would be a fun prank to play on your local vim user
The Evil Ideas thread is thataway…
-
Filed under: An easy mistake to make, I mean, the keys are right next to each other.
A few weeks ago I managed to delete a script I had been working on all day and was about to add/commit, just by running
git clean -fxinstead ofgit clean -fX.
Filed under: I was able to recover it from Eclipse's Local History, though.
-
The point is, no one sat down and figured this is the optimal way to handle navigation so that your fingers are always near everything else and so on. They just copied it the way it was on this forgotten keyboard, and never gave it another thought.
First, there is no "they". It was Bill Joy, who wrote vi for his own use. Other people loved it.
Given that vi and Vim both respond to arrows, why do most users use HJKL? It certainly wasn't because the noobs in the 90s didn't have access to the arrows.
For example, why are all 4 direction keys in the same row? Wouldn't it make sense for up/down to be above/below the other keys?
Why would that make sense? So you'd have to move your hand away from the home row to do the most common editing task? You do know that people have actually compiled typing speed statistics. The home row is the fastest to key.
-
But then again, real speed comes with not moving (or doing other actions) by one character or line at a time…
-
I just changed the movement keys in TF2 from WASD to ASDF, vim-style. Let's see if I can get used to it.
-
A few weeks ago I managed to delete a script I had been working on all day and was about to add/commit, just by running git clean -fx instead of git clean -fX.
You have got to be shitting me.
-x
Don't use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.-X
Remove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files.You are not shitting me. Holy fuck. Case-sensitive FLAGS? Which do the EXACT OPPOSITE THING!?
-
Remember, git is the sort of interface done by people who think OpenSSL is too intuitive.
-
And then there's the insane insecure way *nix shell expands wildcards into file name arguments.
Also, you have a few thousand files you want to delete using wildcards? Tough luck. Better start writing
findscripts...
-
And then there's the insane insecure way *nix shell expands wildcards into file name arguments.
The Windows way — doing it in the receiving process's startup code — is not better, alas, since different programs do it differently. What works for one will fail for another. Jesus H Fucking Christ on a Rocket-Propelled Pogo Stick! Trying to consistently deliver a very specific argument to a subprocess is hard on that platform. With Unix, it's just the shell that's a problem: you can always find a different approach.
(Want to experience this “fun” on Windows at first hand? Try launching a program located in a directory with a space in its name via the
STARTshell utility where that program is not on the PATH and you're not in the same directory tree. Don't forget to put an empty argument first so that your quoting of the full name won't makeSTARTshit itself. “Wonderful.”)
-
You had up/down and left/right arrow pairs, either side of the spacebar, though they were dedicated keys.
C64 did the same retarded thing - to go down, you had to do Shift+Up (or the other way around, or maybe it was CTRL - left my box at home, so I can't test).
I use nano because both vi and emacs confuse me. And I am not ashamed to admit it.
So do I, though it's less "confused" and more "not giving a fuck abut retarded control schemes, just let me edit my file in an intuitive way, instead of requiring me to master a fucking text editor".
Seriously, EDIT.COM was the best thing there was for me, as far as command line editors are concerned. And I'm not ashamed to admit it either.
-
The Windows way — doing it in the receiving process's startup code — is not better, alas, since different programs do it differently. What works for one will fail for another. Jesus H Fucking Christ on a Rocket-Propelled Pogo Stick! Trying to consistently deliver a very specific argument to a subprocess is hard on that platform. With Unix, it's just the shell that's a problem: you can always find a different approach.
(Want to experience this “fun” on Windows at first hand? Try launching a program located in a directory with a space in its name via the START shell utility where that program is not on the PATH and you're not in the same directory tree. Don't forget to put an empty argument first so that your quoting of the full name won't make START shit itself. “Wonderful.”)
Let's be clear, *nix shell is much, much, much better than Windows shell. It's just that on Linux, you're supposed to be doing everything in shell and on Windows, not so much.
-
Seriously, EDIT.COM was the best thing there was for me, as far as command line editors are concerned. And I'm not ashamed to admit it either.
Oh yeah! Exactly what you need for a quick edit and nothing more. Fuck nano.
-
Let's be clear, *nix shell is much, much, much better than Windows shell. It's just that on Linux, you're supposed to be doing everything in shell and on Windows, not so much.
That was true before Powershell, which is damn fucking awesome. It's basically a command line which gives you access to the whole .NET, and then some. While it takes a while to learn the commands, it admittedly does pay off.
-
That was true before Powershell, which is damn fucking awesome. It's basically a command line which gives you access to the whole .NET, and then some. While it takes a while to learn the commands, it admittedly does pay off.
I flirted with it but found it too inscrutable. Maybe if Microsoft was serious about pushing it, I'd give it another go.
-
I flirted with it but found it too inscrutable.
Yep, it is hard to understand. But the sheer power of having every single .NET object available to you, and being able to push it through a pipeline, pretty much compensates for it.
-
I was researching how to add bash completion to my utility scripts. Looking through
/usr/share/bash-completion/bash_completion, I came upon this:# NOTE: Using this function as a helper function is deprecated. Use # `_known_hosts_real' instead. _known_hosts() { #...Yay!
-
From
uname(2):**Underlying kernel interface** Over time, increases in the size of the utsname structure have led to three successive versions of uname(): sys_olduname() (slot \_\_NR_oldolduname), sys_uname() (slot \_\_NR_olduname), and sys_newuname() (slot __NR_uname). The first one used length 9 for all fields; the second used 65; the third also uses 65 but adds the domainname field.
Filed under: FUCKING HELL WHY DOES THE BLOCKQUOTE BUTTON DOES NOTHING TWICE WHEN I CLICK IT ONCE?
-
A few weeks ago I managed to delete a script I had been working on all day and was about to add/commit, just by running
git clean -fxinstead ofgit clean -fX.
While I hate playing the "blame the user" game, this looks like you're doing it wrong. Why are you cleaning (deleting stuff) before committing your work?I have been bitten by something similar when using a Subversion GUI. I prefer to run tests locally before commiting (which would automatically trigger the build system and send "build failed" reports since SVN commits are public). So I cleaned the directory with TortoiseSVN's delete ignored / unversioned and forgot to uncheck my new file. Bam, work lost. Just my own fault really.
That's one of the nice things about git: commits are local, so you can save your work first and do the cleaning later. And if you do notice a mistake during local testing, you can still amend it, or use two commits and a "rebase / squash commit" operation.
-
Though IIRC you had to press another key to get to that, and it was fairly terrible. To the point where most games that needed 4-way movement actually used QAOP for up/down/left/right.
BBC games tended to use
ZX:/, even though the keyboard actually had dedicated arrow keys. Not in an ergonomic format though:
