I tend to fall on the side of adding a command line switch to turn off the function if not desired, but the default could be to strip/modify. The operating system A files compatible with operating system B seems to be more of a job for a translator, not a disk emulator. However if the disk emulator wishes to perform this function, I see no problem with it. I would just think having a command line switch to turn off the function if so desired, would allow for any type of situation should someone choose to do so.
Just my 2 cents worth. Ultimately, it is the software author that makes these decisions, so I'm not going to gripe either way. After all, for what he charges :D, I won't be picky and just be happy to have a utility that works as well as his software does. If I feel the need to send over something as a test like Brian was speaking of, I'll just use an older version that wouldn't strip the characters. Rick On Wed, Feb 13, 2019 at 7:28 AM Jeffrey Birt <bir...@soigeneris.com> wrote: > I have read most of these posts with a mixture of sadness and amusement. > Sadness because people get so upset over something like this and amusement > for the same reason. > > > > Starting from the begging, I open my text editor and type in my text. I > save it and magically an EOF character is appended to the end of the file. > I did not ask for it to be there, there was no dialog box or warning that > it was going to happen. It is an artifact of how the system work. When I > open that text file, I only see my text, the EOF has been stripped from my > file. Again, it is how the system is designed work. > > > > Making system A talk to system B is all about data manipulation. After all > they are two different beasts with different expectations and so the > program that is designed to communicate between them should seamlessly and > silently handle these differences for the user. > > > > For example, an EOF is a valid character on system A but not on system B > so if reading a file on A and sending to B I would not send the EOF. I > might replace it instead with what system B expects to mark the EOF (which > if my faulty early morning memory serves, if you are using a terminal > program to transfer a file you have to hit CTRL-C, or something, to let the > Model T know the EOF has been reached. In effect you are mapping control > characters form system A to system B. > > > > Years ago, I wrote a program to drip-feed GCode to a CNC machine whose > controller had some particular requirements in both the data itself and > handshaking. So, I read in a text file and ‘manipulated’ the data so it > could be sent to the controller without incident. There were no check boxes > to not ‘manipulate’ the data as that was one of the main purposes of the > program and to not do so meant most likely locking up the CNC controller > whilst cutting a part, which is BAD. > > > > Carrying an ideal like “don’t manipulate the data” past any sort of > logical consideration is encroaching on the border of zealotry. > > > > Jeff_Birt > > > > *From:* M100 <m100-boun...@lists.bitchin100.com> *On Behalf Of *John R. > Hogerhuis > *Sent:* Wednesday, February 13, 2019 1:14 AM > *To:* m...@bitchin100.com > *Subject:* Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version) > > > > "That places the obligation on the wrong party." > > It's not a legal issue. It's just functionality. > > Arguing on other turf (FTP, or checksum algorithms, etc) is to totally > ignore the issue. > > But really, you're arguing on the basis of principle that I agree with in > principle, but in real life an engineer weighs the issues and can set ANY > principle aside. > Yes my decision will violate your assumptions in a hypothetical scenario. > I guess. > >
