Earlier quoted context omitted.
set -o pipefail makes common idioms a pain. Consider using head, which simply exits after it has read a few lines. In this case, the input process gets a SIGPIPE and exits with a non-zero exit code: Consider /tmp/test.sh: set -o pipefail yes foo | head $ bash /tmp/test.sh >/dev/null $ echo $? 141
That's a bug IMHO which I reported at http://lists.gnu.org/archive/html/bug-bash/2015-02/msg00052.... I've collated other mishandling of closed pipes at: http://www.pixelbeat.org/programming/sigpipe_handling.html
Bug 1202858 – Restarting squid results in deleting all files in hard-drive
141–150 of 179 posts
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#142Earlier quoted context omitted.
It's hard to trust anyone that would ever depend on such a variable without having some sort of precondition.
"it's hard to trust anyone that writes a dumb bug". Listen to yourself. We've all written dumb bugs. We've all had that one line of code that was an obvious mistake. I still trust people who write a bug here and there because if I didn't I would have to forgo trusting everyone for everyone makes dumb mistakes sometimes.
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#143I love how deadpan the bug report is: Actual results: All files are deleted on the machine. Expected results: Squid is restarted. Not many details yet but it sounds similar to the Steam bug [0] from last year. [0] https://github.com/valvesoftware/steam-for-linux/issues/3671
Except the Valve bug passed their QE process if any and got out into the wild. This is for an unreleased version of RHEL, and was caught....
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#144Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#145Earlier quoted context omitted.
Parent said "This is why as a user I like Apple's OS X sandbox.". This is a bug from 15 years ago, much much before the sandbox feature was introduced. A sandboxed iTunes would have prevented that.
A sandboxed iTunes would also prevent syncing your iPod and importing existing music collections, because those both require access to files outside the sandbox, which is probably why Apple hasn't done that.
[1] See "Powerbox and File System Access Outside of Your Container" at https://developer.apple.com/library/mac/documentation/Securi...
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#146Earlier quoted context omitted.
Parent said "This is why as a user I like Apple's OS X sandbox.". This is a bug from 15 years ago, much much before the sandbox feature was introduced. A sandboxed iTunes would have prevented that.
A sandboxed iTunes would also prevent syncing your iPod and importing existing music collections, because those both require access to files outside the sandbox, which is probably why Apple hasn't done that.
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#147Earlier quoted context omitted.
Except the Valve bug passed their QE process if any and got out into the wild. This is for an unreleased version of RHEL, and was caught....
QE? Is that a misspelling of QA, or is there another meaning beyond Quantitative Easing?
Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#148I love how deadpan the bug report is: Actual results: All files are deleted on the machine. Expected results: Squid is restarted. Not many details yet but it sounds similar to the Steam bug [0] from last year. [0] https://github.com/valvesoftware/steam-for-linux/issues/3671
At the time of this writing, RHEL 6.7 is still pre-beta
and this bug was found in an *UNRELEASED* update to squid.
Bad enough, but not like it's out in production.Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive
#149Earlier quoted context omitted.
That's kind of scary — in that case I guess I should avoid creating a file named -rf.
That is really interesting. Can someone knowledgeable about the shell expand on this? I don't dare test it on my machine.
You can spin up a droplet and use the online shell tool or ssh in (very easy when you've set up a cert as the droplet can have the cert setup automatically).
Then you can mess about with a droplet as much as you like, virtually speaking. Once you're done then use the control panel to destroy the droplet - it costs a few ¢ a day and if you don't have a droplet in use (which means active or paused; preserving images is cheaper but non-zero) then you don't pay anything.
Basically sign up and have a year of uptime to mess with a full install of various OS with no charge.
Make sure you don't write "rm -rf /*" in the wrong terminal!