Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tale of aux.c

heirloom.sourceforge.net

Post reply on HN
Print view View original

101–110 of 129 posts

Re: The tale of aux.c

#101

Post by RHSeeger »

zanchey wrote: post #65
TorKlingberg wrote: post #63

Earlier quoted context omitted.

If we're going to criticise Unix file naming, I'd rather talk about how file names with spaces in them break things, or how hard it is do delete a file named "-".

There's something in my environment that keeps creating a file called "-" in my home directory, and it's driving me crazy.

Open the parent directory with emacs and you can use it to delete the rogue directory/file. Admittedly, there's easier ways for a "-" named file, but its a good solution to know since you can use it to delete even the most difficult filenames.

Re: The tale of aux.c

#102

Post by Sean1708 »

oblio wrote: post #92
jovial_cavalier wrote: post #69

Earlier quoted context omitted.

>My video of my kid's first at-bat, in a file I named a.out, got mysteriously clobbered when I took my first programming class. 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…

> This is a failure to understand [Program X]'s default behavior, not a fundamental flaw with your operating system. 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.tx…

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

Except that example could also happen on Windows.

Re: The tale of aux.c

#103

Post by batat »

drfuchs wrote: post #31

So, you smug Linux guys think it can't happen to you? Well, before you get off my lawn, let me tell you a story... Early versions of FrameMaker kept all resource files (internationalized strings, dialog box layouts, etc.) in the two subdirectories .../FrameMaker/Resources/{Unix,Core} (the first one for the Unix platform-specific resources, and the second for the cross-platform ones also used by the Mac and Windows po…

How to delete "~" directory :) https://askubuntu.com/questions/26466/removing-folder-named

Re: The tale of aux.c

#104

Post by exprA »

batat wrote: post #103
drfuchs wrote: post #31

So, you smug Linux guys think it can't happen to you? Well, before you get off my lawn, let me tell you a story... Early versions of FrameMaker kept all resource files (internationalized strings, dialog box layouts, etc.) in the two subdirectories .../FrameMaker/Resources/{Unix,Core} (the first one for the Unix platform-specific resources, and the second for the cross-platform ones also used by the Mac and Windows po…

How to delete "~" directory :) https://askubuntu.com/questions/26466/removing-folder-named

I.e. “how do I operate my shell”. You certainly want to understand shell expansion to get stuff done effectively.

Re: The tale of aux.c

#105

Post by alexeiz »

drfuchs wrote: post #31

So, you smug Linux guys think it can't happen to you? Well, before you get off my lawn, let me tell you a story... Early versions of FrameMaker kept all resource files (internationalized strings, dialog box layouts, etc.) in the two subdirectories .../FrameMaker/Resources/{Unix,Core} (the first one for the Unix platform-specific resources, and the second for the cross-platform ones also used by the Mac and Windows po…

I hope that customer paid you enough for you trouble. But obviously it wasn't as much as it would have cost them to fix their crappy cron script.

Re: The tale of aux.c

#106

Post by to3m »

Theodores wrote: post #86
Triave wrote: post #50

Earlier quoted context omitted.

ADFS allowed directories, but used "." as the separator, giving you paths like "Letters.Memo1". Were you thinking of DFS?

You couldn't do hierarchy though, it was only one deep.

That was true for DFS, but not ADFS.

Re: The tale of aux.c

#107

Post by jdboyd »

trothamel wrote: post #8

Even if Microsoft keeps this behavior, I'm surprised they don't modify it to check the filename extension. It's one thing to change a device like CON that people might expect to exist, but it seems like not distinguishing CON and con.c is just asking for trouble.

Or they could have at least removed the behavior when in 64bit mode.

Re: The tale of aux.c

#108

Post by jovial_cavalier »

zanchey wrote: post #100
jovial_cavalier wrote: post #68

Earlier quoted context omitted.

By convention, when a unix program is passed "--" it means there are no more flags being passed. Try the following: $ rm -- -

Oh, I can remove it... And a few hours or days later it's back!

Okay, you're gonna want to type $sudo crontab -e...

Re: The tale of aux.c

#110

Post by _jal »

oblio wrote: post #92
jovial_cavalier wrote: post #69

Earlier quoted context omitted.

>My video of my kid's first at-bat, in a file I named a.out, got mysteriously clobbered when I took my first programming class. 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…

> This is a failure to understand [Program X]'s default behavior, not a fundamental flaw with your operating system. 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.tx…

Looks like it is time for this again...

> 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.

Post reply on HN