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

111–120 of 129 posts

Re: The tale of aux.c

#111

Post by kps »

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…

  > For those that don't remember how tar works, the arguments are reversed compared to, say, cp.
Tar doesn't have positional file arguments; you use the 'f' flag to specify an archive file. You might be thinking of zip or some similar archiver in the DOS heritage.

Re: The tale of aux.c

#112

Post by gkya »

inopinatus wrote: post #83
gkya wrote: post #60

Earlier quoted context omitted.

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, not only did they do exactly that, they could even be induced to do so through a symlimk, with hilarious results.

I'm really curious about them hilarious results now :)

Re: The tale of aux.c

#113

Post by YSFEJ4SWJUVU6 »

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

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

Re: The tale of aux.c

#114

Post by bitwize »

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…

The lesson here is "suck it up and build software for the systems your customers use, not the ones you wish they used".

Re: The tale of aux.c

#115

Post by HankB99 »

pjmlp wrote: post #49
Grom_PE wrote: post #13

On Windows, paths can be accessed with \\?\ prefix: mkdir \\?\V:\con notepad \\?\V:\con\aux.txt This avoids reserved filenames as well as 260-character length restriction. But many programs that try to do any path processing fail after seeing an unexpected prefix, even File Open dialog (on Win7 at least).

It was finally fixed on Windows 10.

Last time I tried I was still unable to create the file '.gitignore' on Windows 10 using the file browser. It insisted that I enter a file name and did not consider '.gitignore' an acceptable file name. It is possible to create that file using other tools such as an editor so it's a user interface shortcoming and not a filesystem shortcoming.

Re: The tale of aux.c

#116

Post by imglorp »

Dylan16807 wrote: post #81
pjmlp wrote: post #49

Earlier quoted context omitted.

It was finally fixed on Windows 10.

Not really. Windows 10 made it easier in certain ways for a program to support long file names. But it still requires explicit support, and programs can and did support it previously. And importantly explorer still doesn't support it properly.

Hell, 8.3 filename creation is still enabled by default on 10. WTF?

https://technet.microsoft.com/en-us/library/cc959352.aspx

Re: The tale of aux.c

#117

Post by oblio »

kps wrote: post #111
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…

> For those that don't remember how tar works, the arguments are reversed compared to, say, cp. Tar doesn't have positional file arguments; you use the 'f' flag to specify an archive file. You might be thinking of zip or some similar archiver in the DOS heritage.

My bad, I was actually talking about a very common tar idiom which is almost an automatism for me:

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

Re: The tale of aux.c

#118

Post by codedokode »

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

It is better to write EDITOR=nano sudo crontab ... otherwise instead of edititng the crontab you will be solving the problem of exiting vi.

Re: The tale of aux.c

#119

Post by Dylan16807 »

HankB99 wrote: post #115
pjmlp wrote: post #49

Earlier quoted context omitted.

It was finally fixed on Windows 10.

Last time I tried I was still unable to create the file '.gitignore' on Windows 10 using the file browser. It insisted that I enter a file name and did not consider '.gitignore' an acceptable file name. It is possible to create that file using other tools such as an editor so it's a user interface shortcoming and not a filesystem shortcoming.

That one has a trick to it! Explorer rejects filenames that are "just extensions", but that's just a strong opinion it has. At the same time, there is a behavior that filenames ending in periods are actually invalid, and get the periods silently stripped by win32. So type ".gitignore." to name a file .gitignore

Re: The tale of aux.c

#120

Post by condescendence »

jstanley wrote: post #59
condescendence wrote: post #24

>But nowadays, people confuse Microsoft Windows, the successor to DOS, with a Unix operating system, and want to run mailx on it. ...huh >If you want to use mailx, there is the technically and morally sane option of using a free Unix implementation. I mean it's really not that hard to release a Windows compatible version. You change a single file name? This just sounds like throwing gas on the flame war that is unix…

It was written in 2007. There was much greater tension between Microsoft and free software at that time.

yeah I just noticed that, good point. Although releasing as much OSS/Free software to every OS (regardless of status) would have been a better fighting route than "*uck you."
Post reply on HN