The first, `core`, isn't relevant. `/proc/sys/kernel/core_pattern` configures that value, and by default it's named "core.$PID" nowadays.

That's far better than windows' wart since it's configurable, disableable, etc.

Your second example is even more contrived. If you run a tool which writes files, of course it can overwrite files. I don't complain that in windows when I type "copy foo bar" my "bar" file is overwritten by "foo".

In the same way, someone who voluntarily runs "gcc x.c" or "cat > foo" should not be surprised when "a.out" and "foo" respectively are overwritten.

There's a massive difference between an unconfigurable gotcha based on a filename and an explicit action which writes a file.

https://inopinatus.org/2015/08/24/privilege-escalation/ has the detail.

This is a failure to understand GCC's default behavior, not a fundamental flaw with your operating system.

The "core" thing is a little more understandable, but it can all be remedied by choosing reasonable filenames with accurate file extensions. "aux.c" isn't that unreasonable, and if I'm reading it right, he could've called it "aux.foo" and it still would've been broken.

Ah, yes, the age old Unix trope of, "it's not the system, it's the user's fault".

As a Linux user for many years, that doesn't excuse such boneheaded errors. By default no application should clobber existing files, unless asked to. Avoid data loss and all that.

Heck, I remember back when:

tar myfile.txt myarchive.tar

would result in myfile.txt being truncated to 0 bytes (therefore deleting its contents) and a snarky message that myarchive.tar can't be archived because it can't be found.

For those that don't remember how tar works, the arguments are reversed compared to, say, cp.

At least I think they've fixed it, newer tar version says something like "Cowardly refusing to create an empty archive".

The Unix ecosystem, dragged kicking and screaming towards user-friendliness since 1970.

Well, if the user had read the manual before using GCC, it wouldn't have happened.

Regardless, I don't blame them or look down my nose at them. It's bad design. If it's anyone's fault, it's GCC's. But it's certainly not a problem with Unix. This makes it incomparable to the system-level issue of having global filenames like DOS did, apparently.

While Unix was kind of Ok, when coupled with its common userland utilities, the whole often felt like a cactus. Possibly useful, if you don't mind the scars :D

Of course, the man page is a great resource for looking things up, but I can't imagine many people sit down with GCC's man page and actually read it through.

Except that example could also happen on Windows.

  > For those that don't remember how tar works, the arguments are reversed compared to, say, cp.

tar cvf/czvf/cjvf archive files (or -cvf/-czvf/-cjvf).

I don't think I've ever seen anyone actually using tar by going:

tar -c files -f archive

Online tutorials seem to also use my form: http://www.thegeekstuff.com/2010/04/unix-tar-command-example...

Either way, bad form, I'm glad they fixed it :)

> Ah, yes, the age old Unix trope of, "it's not the system, it's the user's fault"

Ah, yes, the age-old complaint that a car driver should be able to run a forklift with no practice.

I don't think Unixen should strive for 'user friendliness'. Hacking in "Do you really want to" dialogs would (a) be contrary to all expectations developed over a long time, (b) break a lot of existing software, (b) annoy the bloody hell out of everyone, and (d) not solve anything, because those dialogs don't prevent mistakes.

Not all systems need to converge, and Unix has been a professional toolchain since the beginning. You're expected to know something about it, just like you don't let kids run plasma cutters.

$ rm -- -

The problem is names that could be interpreted like options, like '-f' or '--help'.

This means, if you're in a directory with the files a, b, -rf, and the directories foo/ and bar/, running "rm * " will not delete all the files and keep all the directories; instead it will be turned into "rm a b bar foo -rf", meaning it will delete all the files and directories except for the file -rf.

  rm -- -

That snark isn’t necessary. It’s easier to use a web browser than to delete a file called - from the terminal. Or haven’t you used a non-GUI system before?

Everything has a learning curve, of course, but are you sure you're just not much more familiar with one of these two?

(edit: just to clarify, what do you expect a decent rm to do when given a single argument of “-”? While there may still be systems where that does not do what you'd expect it to do – it's no different to existing obsolete versions of browsers that do nothing at all when you type in something other than a valid URL in the address bar – and are thus considerably harder to use for some not familiar with the technology. The harder corner case would be to try and remove a file with name that can be confused for a valid flag – like '-i' – but even then, that's about the only corner case for the tool, and not a steep step to learn. Any recent coreutils rm will even suggest a valid command to remove files that look like options, but are not actually valid options, so some thought has been given to discoverability as well.)

Not saying it's remotely likely, just saying that having video files in a program's source tree isn't the only way it could happen :)

Linux still does, though many distros set ulimit or /proc/sys/kernel/core_pattern to disable it.