That places the obligation on the wrong party. This is computers not inpressionist art. If I am trying to figure out why something is, or is not working, or document something by experiment, it's wrong to have a low level tool responsible for handling data do something, *especially* without notice or configurability, like modify the data as it passes from point A to point B.
If I have a file, that has some garbage data in it that is actually invalid, but it works *anyway*, because one of the tools I just happened to use did some clean up for me, then I now think I know what the correct data is. I just "proved" it because it worked. Meanwhile, it's actually bad data, and doesn't work in any other context. It wouldn't work on a real disk, or on any other emulator or device that didn't happen to have the same *backwards* idea about being "helpful". But I, not knowing any better, tried something, it worked, I wrote it all up on a web site, provided a download archive of all bad files, and years later someone else spends all day banging their head against the wall and throwing away their "broken" vintage machine because it isn't working... (In case we are not all up to speed, this is a hypothetical. I am not saying I actually did this as was so mystified and produced a load of bad files. You asked for an example.) In the last 20 years as a sysadmin, programmer, all around IT analyst dealing with all kinds of boring back-end integration projects; that feature of the "venerable" ftp has only ever caused grief and cost time and money over and over again. The reasons it's wrong to modify your payload unless that is your actual explicitly declared purpose is to *process* it in some way, are open-ended and infinite. You can't know the possible reasons or situations which might ever come up with the countless possible users in their countless possible contexts in the open-ended future years. But you don't have to. All you have to know is that if you don't make any assumptions, then you don't have to worry about breaking them, or failing to think of everything. Any example will by definition be a contrived example, which is too tempting (for some) to disregard. Any contrived example just sounds like some unlikely thing that isn't important to worry about. whatever the example is, you just say "oh that's all? who would do that? just don't do that, that's all" It's user-hostile, even if intending to be the opposite. It's a misguided concept of being helpful. On Tue, Feb 12, 2019, 10:08 PM Gary Weber <[email protected] wrote: > Brian, describe ANY scenario at all, where cleansing trailing <EOF> > characters from transmitted .DO files into a Model T file system, is a > wrong idea. I'm genuinely interested. :) > > On Tue, Feb 12, 2019 at 7:28 PM Brian White <[email protected]> wrote: > >> I referenced ftp as the canonical *anti-example* in my first comment and >> then again later. >> >> It proves how wrong the idea is, not how right it is. >> >> On Tue, Feb 12, 2019, 6:53 PM Gary L Phillips <[email protected] wrote: >> >>> I'll just add one small note here. >>> >>> No less venerable a program than ftp, as implemented on dozens of >>> environments, makes changes to data being transferred. It does so by >>> default and without warning, to adjust text files from one system standard >>> to another. The obvious case here is automatic conversion of line endings >>> between CR (as used by many early microcomputer systems,) LF (as used by >>> most *NIX compatibles and Apple systems,) or CR/LF (as used by PCDOS and >>> MS-DOS.) >>> >>> And yes, this does sometimes cause corruption or confusion when binary >>> data is transferred, unless the user specifies that the data is binary and >>> to be left untouched. >>> >>> Gary Phillips 😉 >>> >> > > -- > Gary Weber > [email protected] >
