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

91–100 of 129 posts

Re: The tale of aux.c

#91

Post by exprA »

ComputerGuru wrote: post #85
exprA wrote: post #73

Earlier quoted context omitted.

>I'd rather talk about how file names with spaces in them break things Not really a Unix thing, but some tools (rather common even) are indeed very broken when it comes to certain types of file names. However... >how hard it is do delete a file named "-" While it's certainly a corner case of sorts, if you call that task hard, I wonder how you fare with using more complex software, like a web browser...

> I wonder how you fare with using more complex software, like a web browser... 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?

I don't agree with that at all; a web browser has easily a more complex user interface than a single-purpose command-line tool like “rm” – and that is even before we open any document at all, with all their conventions we have to learn before we can effectively navigate them.

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

Re: The tale of aux.c

#92

Post by oblio »

jovial_cavalier wrote: post #69
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…

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

Re: The tale of aux.c

#93

Post by jovial_cavalier »

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

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.

Re: The tale of aux.c

#94

Post by Arnavion »

captainmuon wrote: post #51
colejohnson66 wrote: post #45

Earlier quoted context omitted.

Or they could just create a registry flag that enables the backwards compatible behavior. Then all default installs don't have the "bug", while those that need it can enable it.

They could probably make the new behavior opt-in in the application manifest. Without a manifest, you'll see pre-XP common controls, and GetVersion will return an old version, so every modern application has it anyway.

Batch scripts don't have application manifests (nor, to the sibling comment, a compat mode setting).

Re: The tale of aux.c

#95

Post by oblio »

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…

Well, as far as modern design goes, I doubt many people argue that Unix was better designed than DOS. DOS was a single user, single tasking OS meant for very limited hardware.

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

Re: The tale of aux.c

#97

Post by pjmlp »

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.

It just requires enabling it, no special care from applications.

It is disabled by default due to backwards compatibility.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

The file explorer does not support it on purpose.

https://superuser.com/questions/1114359/windows-10-home-anni...

Re: The tale of aux.c

#98

Post by sevensor »

feelin_googley wrote: post #48

If I had to guess I would bet that none of the commenters in this thread have ever used the Heirloom version of "mailx", and some have never used, or would ever want to use, the BSD mailx either. It is a shame because I think Mr. Ritter deserves more recognition for his work. IMHO, some of his versions are real improvements over the BSD ones, e.g., troff (doctools) and nailx. I for one am very thankful for the Heirlo…

I know of him through the version of vi that comes with Arch. I really appreciate that there's somebody keeping a conservative version of vi around. Even if I'm mostly going to use vi-like editors with more features, I'm glad there's a vi to fall back on.

Re: The tale of aux.c

#99

Post by Dylan16807 »

pjmlp wrote: post #97
Dylan16807 wrote: post #81

Earlier quoted context omitted.

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.

It just requires enabling it, no special care from applications. It is disabled by default due to backwards compatibility. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... The file explorer does not support it on purpose. https://superuser.com/questions/1114359/windows-10-home-anni...

Once you enable that, it still only works on applications that explicitly declare support in their manifest.

The backwards compatibility here is only in the fine details of how you deal with long paths. The old way and the new way both require application support. The new way is easier, but the old way worked fine even on XP and earlier.

This setting isn't actually future-looking. It was already possible to make these files with certain tools. And they could have let it always be on for programs that support it. This setting exists so you can signal to programs that they shouldn't use long paths, even when they are capable of it.

> The file explorer does not support it on purpose.

Sure, it's on purpose, but it's a good example of how impotent the setting is.

Re: The tale of aux.c

#100

Post by zanchey »

jovial_cavalier wrote: post #68
zanchey wrote: post #65

Earlier quoted context omitted.

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

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!
Post reply on HN