Worst line of BASH ever?
-
Found this in a BASH script i was debugging. I took the comment at face value at first, but... well i'll just show you the code.
#Get the directory of the current input file for later processing _DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"; export _DIR;nope. that comment is a lie. that gets the directory name of the bash file, not the input file.
$> svn blame %BASH_FILE% 60 accalia [unrelated commit comment] 59 accalia [unrelated commit comment] 21 accalia [unrelated commit comment] 19 accalia [unrelated commit comment] 14 accalia [unrelated commit comment] 9 accalia Change getting current directory from `dirname` to better handle symlinks and bind mount points (why do we even support that?!) 5 accalia Initial commit of %BASH_FILE% $>http://stream1.gifsoup.com/view6/2709062/picard-double-facepalm-o.gif
I am TRWTF, unless someone can top that line?
-
It is bad, but I'm assuming that you just hadn't fully tested it with useful cases before committing it.
-
Quite possible. That file is well over a year old and it only recently started to fail regularly. Looking back on all the old failure reports they all happen when the file to process happens to reside in a different folder than the script (which was not the common case until recently)
Still, I would have expected myself to test that a bit better before i made that assertion in the commit comment. particularly since i fixed it by rolling back the change i made in revision 9.
-
Testing your own code with actual usage in odd combinations exposes a number of bugs that you would find quite surprising when original writing the code.
-
Testing your own code with actual usage in odd combinations exposes a number of bugs that you would find quite surprising when original writing the code.
I was doing some Unicode fixes to an old codebase which had some half-hearted attempts already done. I guess none of them ever expected to sell Nestlé products. Unfortunately forcing everything to Unicode really slows perl down. Fortunately because of my recent changes I knew what to change and fix it completely without native Unicode!
-
This seems to be really bad:
rm -rf --no-preserve-root /
-
Doesn't count, that's not bash
-
EXCUUUSE ME, PRINCESS
#!/bin/bash rm -rf --no-preserve-root /
-
i'd say that doesn't count too, but not for the same reason as @cartman82
I'd say that doesn't count because it's clearly mallicious, rather than just overly obtuse and difficult to understand.
now if it were something like this i'd be inclined to agree with you.
#!/bin/bash # DANGEROUS! Use with caution alias remove='rm -rf --no-preserve-root' # [snip] 400 lines later remove $baseeDir/$TAARGET; #ed. the variables are misspelled, and so always unset
-
+1(Idiotic)
-
yes, that it is. as is just about any use of the
--no-preserve-rootflag in a script.there is a reason that flag was added. the use of that flag is so dangerous that in most of the systems i administer at work i've replaced
rmwith a shell script that errors out if that flag is passed and otherwise calls the originalrmwith the provided argumentsit has not taken my coworkers long to become very annoyed at my servers because their scripts fail on my servers. they're even starting to use that flag less in their scripts! who said old engineers can't learn new tricks?
-
it has not taken my coworkers long to become very annoyed at my servers because their scripts fail on my servers. they're even starting to use that flag less in their scripts!
Why? Why would they even do that in the first place?
I've never had occasion to use
--no-preserve-rootmyself, but according toman rmits only effect is to remove the special treatment of/, so literally the only reason for using it is if you are actually trying to remove/. I hope your coworkers are not trying to do that on your servers, but if not, why are they using it at all?
-
I've never had occasion to use
--no-preserve-root
Because there isn't really one - if you want to do that much damage to the running OS why not just format it?
-
And of course
rm -rf /*will still work last I checked...
-
if you want to do that much damage to the running OS why not just format it?
Format? Pff, my grandma can do format. Where's the fun in that?
Witnessing the system eat itself, file by file, removing its vital organs one by one - that, on the other hand...
Filed under: for added amusement, stop rm -rf / midway through
-
You're not wrong. At least it won't work twice.
edit- and despite the prompt, aptitude thinks gzip is still installed so the command won't actually install it.
-
Filed under: for added amusement, stop rm -rf / midway through
I'm especially impressed by
rmmanaging to delete itself.
-
I'm especially impressed by <code>rm</code> managing to delete itself.
Unlike Windows, Linux doesn't lock files that are currently in use. For that matter, locking on UNIX is mostly just advisory anyway.
-
I cannot start a post with a quoted block? Then I'll write something above...
#!/bin/bash :() { :|:& } ;:Yes, I used to run this when I was younger - and it took me a while to understand why it brought my machine down (no ulimits set and running it as
root)
-
Which is simultaneously the best and worst feature of Windows.
Actually it's kind of simultaneously the best and worst feature of Linux, too. Considering how many Linux users think they don't need to reboot after updates. (Uh, you kinda do buddy, your apps are all using the memory-copy of the buggy/insecure library until you quit every single one at the same time, including the desktop environment and windowing system. Conveniently, there's an easy way to do that: reboot.)
-
For security-related updates I usually get a "Please reboot now" (Linux Mint). If it's just some random non-sec updates it's all like "do whatever the fuck you want."
In any case I don't reboot for the security updates anyways because I like living dangerously. That and looking at my BIOS makes my eyes bleed. Also the last time this was a problem was approximately never.
-
Ubuntu requires you to reboot after an update now, at least if you're using the desktop.
-
Unlike Windows, Linux doesn't lock files that are currently in use. For that matter, locking on UNIX is mostly just advisory anyway.
There's a sort of lock. The inode still has a reference to it, but it's no longer reachable from the directory structure. The real advantage of that is that it lets you do an update to a library on a service machine that must stay available; you don't need to reboot to make things work.
Not so important these days. Most people doing DevOps just federate their production service machines now, so losing one while it restarts isn't such a big deal.
-
you don't need to reboot to make things work.
Except you do.
There is no circumstance in which it is desirable to update a library or application that is "ghosted" in memory. Allowing it is a recipe for disaster, which is one of the main reasons Windows doesn't allow it.
The best-case scenario is people think they're updated when they aren't. The worst case is your updated code calls non-updated code and it's crash city USA.
-
-
Which is simultaneously the best and worst feature of Windows.
Actually it's kind of simultaneously the best and worst feature of Linux, too. Considering how many Linux users think they don't need to reboot after updates. (Uh, you kinda do buddy, your apps are all using the memory-copy of the buggy/insecure library until you quit every single one at the same time, including the desktop environment and windowing system. Conveniently, there's an easy way to do that: reboot.)
Idea for a ld.so feature: dynamically reloading the code segment of a library that gets modified while opened. Scary? Cool? Meh?
Filed under: ksplice, just not quite as scary or cool
-
Scary. What if a struct definition was updated?
-
There is no circumstance in which it is desirable to update a library or application that is "ghosted" in memory. Allowing it is a recipe for disaster, which is one of the main reasons Windows doesn't allow it.
Lies. I benefit from this all the time. "Firefox must be restarted for the updates to take effect." OK Firefox, as soon as I'm done working / watching this thing, thanks. I'd rather risk a crash than force the equivalent with a restart. The possibility of a browser crashing is a very small price to pay. This is true for almost all apps. Plus, it never seems to happen anyway.
Forced restarts make me want to shoot myself, especially when I'm in a hurry.
-
The possibility of a browser crashing is a very small price to pay.
The possibility of replacing your whole cache with that Rosie O'Donell nude pic you stumbled upon lately, due to purging code being live-patched into writing-to-disk code, however...
-
The possibility of replacing your whole cache with that Rosie O'Donell nude pic you stumbled upon lately, ...
I don't think "stumble" is the right word. And I have it fullscreened on my third monitor at all times anyway, so what does that matter?
-
There is no circumstance in which it is desirable to update a library or application that is "ghosted" in memory.
These days, people don't so much. It used to be a lot more common.
-
Well it's one of those things where it's possible if you can guarantee X, and guarantee Y and guarantee Z and you don't do Foo while it's going but...
There's so many gotchas, I like my rule of thumb.
-
Best case is that the upgrade scripts restart the service for you.
This is also the common case.
-
aptitude and apt-get (command line tools) don't outright tell you.
Until the next time you log in that is, then they put
**System reboot required**(or something similar) at the end of the message of the day.Ubuntu 14.04 seems to have screwed that up, too. Now it sometimes doesn't update the number of packages that can be updated which seems to control the reboot prompt as well.
-
Ubuntu 14.04 seems to have screwed that up, too. Now it sometimes doesn't update the number of packages that can be updated which seems to control the reboot prompt as well.
I would have been shocked if Ubuntu hadn't screwed that up. I mean they screwed up everything else, so why not this?
-
I would have been shocked if Ubuntu hadn't screwed that up. I mean they screwed up everything else, so why not this?
To mess with people. Duh.
-
My Ubuntu Server 12.04 at login demands a reboot to finish the upgrade to 14.04. But rebooting apparently does nothing and it stays at 12.04 with the login message demanding a reboot to finish the upgrade to 14.04.
-
Reboot harder.
-
I had a windows update that would do that, except it would spend ten minutes installing the update, give up, reboot, roll back the install (another ten minutes), reboot, go "oh, hey, I have this update to apply" and start over. I forget how I fixed that--might have been "reboot in safe mode and manually install the updates one at a time."
-
I would have been shocked if Ubuntu hadn't screwed that up. I mean they screwed up everything else, so why not this?
Well, the thing is... it was working correctly on 12.04. I did a complete format and reinstall when moving to 14.04 to avoid importing cruftiness and because this box just hosts a Team Fortress 2 game server and C/C++ compilation environment.
In other words, it's not because stuff got imported from the old OS.
-
-
Something else Ubuntu got wrong
And Jeff is there closing and unpinning topics, of course.
-
Wow with all of the "volunteer forum admining" he does, how does he have time to design great software?
Oh. Right.
-
Jeff wouldn't know design if it slapped him in the face (which we did), and I don't even want to get into what Jeff thinks is great (compared to what we might)
-
I browsed around in the feedback section a bit and noticed:
-
I'm also seeing some weird scrolling behaviour in this topic; whenever I scroll to the bottom (below the suggested topic list) it bounces me back up a few lines.
