>the only reason a shim is needed is because some other program did
something bad...
Which program is that for example, exactly?
If we were reading punched cards, would the keypunch be "bad"?
Or, in a modern context, which one is *bad*, Notepad or Wordpad? You
suggest that Notepad is bad whereas it does exactly what you want,
i.e. it does not modify the file, often leaving it unreadable.
When moving files between 'NIX and MS-DOS, with a "shim" that adjusts
line endings as appropriate, which side is the "bad" one?
We're talking about transferring files between two systems, one of
which is long obsolete, that are incompatible in various ways,
including file names, character sets, EOF determination etc.; we know
what the systems at each end are, so we can automatically make the
necessary adjustments.
Considering how many people still have trouble transferring files as
is, the simpler and straightforward we can make it for new users the
better IMO.
The question that should have been asked in the very beginning: What
alternative do you propose?
----- Original Message -----
*From:* Brian White <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Wednesday, February 13, 2019 9:02 PM
*Subject:* Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
That, (other systems), is a great example of yet another
unpredicted yet valid situation.
What if one reads the description on the tin for the tpdd
emulator, which says it emulates a tpdd...
So they try to use it with a Brother sewing machine. Is it
harmless to upper-case the filenames or modify the contents of
files in that case?
Maybe the sewing machine doesn't happen to use files named *.DO,
or maybe it does, or maybe the names can be anything including .DO
with no special meaning?
Someone also mentioned upper-casing the filenames. Since when is
that an automatic safe assumption? I can create filenames with
lower case letters perfectly fine on a real machine.
All of the situations mentions where the munging is supposedly
helpful, are what's called shims, and the only reason a shim is
needed is because some other program did something bad, and now
you have to do something bad as well, in the opposite direction,
just to get the final result that is the same as if neither thing
had done something bad, IE even the shim admirer is working
towards un-munging data that someone else munged, and therefore
admits the goal of not munging data!
The text editor example is just like ftp. Ancient text editors did
that (and really crappy current ones), like ancient ftp. Since
then, the idea has been recognized as more harmful than helpful,
and nobody does it any more. ftp clients still do it because they
are just adhering to the original standard. But the standard is
old, and newer standards don't do it. http does not do it. (http
clients & servers may negotiate things like gzip compression
in-flight, but the data going in one end comes out the other end
faithfully)
That behavior of some old text editors to re-write line-endings or
append an eof, exists, but is also recognized as a *bad* thing,
which is why anyone doing any kind of actual work with tex files,
not just programmers but anything like examining EDI transactions
or literally anything, are told not to use notepad.exe, but to
install notepad++ or any "prgrammer" editor. none of vi, vim,
emacs etc do such things, etc. Why not? Is it because in 40 years
no one has gotten around to adding this clearly helpful feature?
Wherever you feel a need for a shim, it's a necessity to correct
for someone/something else's undesireable behavior, not a
supporting argument for doing the same thing some more.
It's bad enough that we do some other smoke & mirrors with special
filenames in order to implement subdirectory support. I don't
remember off-hand if foo.<> is a possible legal filename that a
M100 could create or not. It's a very useful feature to be able to
have subdirectories, but even this could theoretically screw
something up that was otherwise legal. For instance, is it
legal/possible for a program to create a file named foo.<> which
is just used internally by the program, never loaded in TEXT or
TELCOM etc? If so, next question can that file be saved & restored
to a real disk the same as any other file? If so, then is that
application simply broken and unusable with any tpdd emulators
that implement TS-DOS directories? Are there any safe assumptions
about filenames like that wrt other clients like sewing machines
and synthesizers? It's such a useful feature, and it's been a de
rigueur standard for so long by now that even *I* would not
suggest that any sane tpdd emulator should remove it. :)
I don't remember from last time I was looking, maybe that
theoretical possibility is actually allowed for by the tpdd server
recognizing, or failing to, that the client supports or expects
the feature, and maybe NOT treating those filenames specially, or
sending filenames like that to show directories, if the client is
not TS-DOS?
--
bkw
On Wed, Feb 13, 2019 at 4:53 PM Kevin Becker
<[email protected] <mailto:[email protected]>> wrote:
An option to not crash the system but also account for some of
the scenarios Brian suggested would be to create a log file
that details any file manipulations that happen during a
transfer. That could be useful to some developer trying to
write a TPDD emulator for some other platform in the future.
On Feb 13, 2019, at 4:30 PM, Gary Weber <[email protected]
<mailto:[email protected]>> wrote:
Good point, Mike. I actually think I support the opt-out
feature, just as long as the name of the switch on the
LaddieAlpha.exe command line is --allow_file_system_corruption
On Wed, Feb 13, 2019 at 2:20 PM Mike Stein
<[email protected] <mailto:[email protected]>> wrote:
Give up, John; just add a -EOF CLI option as requested
and let the user guess which one will crash the
system, or better yet a checkbox:
"Crash system after loading (Y/N)?"
Most ridiculous argument I've read in a long time; why
burden an inexperienced user with a choice that he/she
might not understand when one of the two options will
crash the system?
A good program IMO does its job with as little confusion
and/or risk for the user as possible, regardless of some
irrelevant CS101 "principle."
Maybe just mentioning in the documentation that an
inappropriate CTL-Z will be stripped and the extension
changed if necessary will satisfy the zealots...
Sheesh!
----- Original Message -----
*From:* John R. Hogerhuis <mailto:[email protected]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Wednesday, February 13, 2019 2:14 AM
*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.
That's what I did here, I set a principle aside,
because there is zero, or really, negative, value in
inloading a character that crashes the machine.
The exception to the rule serves the greater good,
such as it is with our little hobby. But I make
decisions just like this in work, and it is part of
what makes me a good engineer.
-- John.
--
Gary Weber
[email protected] <mailto:[email protected]>
--
bkw
