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

121–129 of 129 posts

Re: The tale of aux.c

#121

Post by mort96 »

jovial_cavalier wrote: post #93
oblio wrote: post #92

Earlier quoted context omitted.

> 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". 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, ap…

I'm a professional software developer (well, "professional"; I have a part time programmming job next to studies), where I program in C++, compiling with GCC. I have never read GCC's manual. Expecting newcomers to read the 18 thousand lines of man page before trying to make a program isn't reasonable.

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.

Re: The tale of aux.c

#122

Post by mort96 »

YSFEJ4SWJUVU6 wrote: post #113
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 "-".

While GNU's not unix... afaik GNU coreutils' rm has done exactly what you expect it to when given a single dash as an argument for who knows how long. The problem is names that could be interpreted like options, like '-f' or '--help'.

Interestingly, when the shell expands * , it won't do anything to make sure files starting with - are handled properly.

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.

Re: The tale of aux.c

#123

Post by mort96 »

gkya wrote: post #60
drfuchs wrote: post #41

Earlier quoted context omitted.

A more direct (though fictional) illustration that Unix also has reserved file names that you'd better avoid: "I was writing a novel about digging to the center of the Earth, entitled "core". One day I was running some program that crashed, and my novel turned into a bunch of binary gibberish." Or how about: "My video of my kid's first at-bat, in a file I named a.out, got mysteriously clobbered when I took my first p…

You don't really put videos into a program's source tree. Also I don't think any modern Unix-like OS would overweite a file with a core dump no matter what is the name, and doubt that ancient versions did so too. Having the same set of device files under every directory is quite a different thing.

Actually, when I just want to test something silly, I often just go to ~, make a file test.c or something, write the short test program, and run `gcc -o test test.c`. It's not that rare to have videos in your home directory, and if I had one named a.out, and forgot the -o option, it'd get overwritten.

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 :)

Re: The tale of aux.c

#124

Post by ComputerGuru »

ComputerGuru wrote: post #87
spullara wrote: post #15

In 1991 I was working at a place with a Novell Netware network. I decided to make a system that would execute remote commands by writing them to a shared directory and other machines would see the files and execute the commands. I named those files COMXXXXX.TXT where the X's were a random number (yeah, that was a bad idea). Every few days the system would hang and stop working. I finally narrowed it down to the rando…

To be fair, that was not at all obvious from your tersely worded post.

I’m sorry, I seem to have fat fingered it and replied to the wrong post.

Re: The tale of aux.c

#125

Post by zanchey »

jovial_cavalier wrote: post #108
zanchey wrote: post #100

Earlier quoted context omitted.

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

All the interest encouraged me to dig in and find it, and it turned out to be in one of zsh's many startup scripts.

Re: The tale of aux.c

#126

Post by xelxebar »

mort96 wrote: post #122
YSFEJ4SWJUVU6 wrote: post #113

Earlier quoted context omitted.

While GNU's not unix... afaik GNU coreutils' rm has done exactly what you expect it to when given a single dash as an argument for who knows how long. The problem is names that could be interpreted like options, like '-f' or '--help'.

Interestingly, when the shell expands * , it won't do anything to make sure files starting with - are handled properly. 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…

I've definitely run into this on bash and zsh (iirc). I'm curious if this glob expansion behaviour is set in posix somewhere.

Re: The tale of aux.c

#127

Post by boomlinde »

_jal wrote: post #110
oblio wrote: post #92

Earlier quoted context omitted.

> 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 exist…

"My video of my kid's first at-bat, on a DVD in front of my plasma cutter, got mysteriously clobbered when I turned the cutter on."

Re: The tale of aux.c

#128

Post by [deleted] »

TorKlingberg wrote: post #63
drfuchs wrote: post #41

Earlier quoted context omitted.

A more direct (though fictional) illustration that Unix also has reserved file names that you'd better avoid: "I was writing a novel about digging to the center of the Earth, entitled "core". One day I was running some program that crashed, and my novel turned into a bunch of binary gibberish." Or how about: "My video of my kid's first at-bat, in a file I named a.out, got mysteriously clobbered when I took my first p…

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

[deleted]
Post reply on HN