[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

No Subject



 > The Mac has 256 "ASCII" characters, half of which are created with the
> option key. They have never caused me problems on Mac's but such
characters
> are often truncated to 7 bits during transfer. That can cause on of them
to
> become a control character which can muck up a later transfer in TEXT
mode.

Oh, thank you! I have wanted a good explanation for this from the beginning!
Where does the "bare line-feeds" error come from during transfers?

> "TEXT" transfer programs typically attempt to make adjustments when they
> pass files from one environment to another and they often get it wrong.

I think "often" is actually closer to 80% (or so) of the time! How "evil"
that these FTP prog.s don't have an ultra simple way of forcing ASCII
"correctness" on all files with allowed ASCII extensions.

> TEXT ftp is fairly reliable.

Humbug.

> BINARY ftp never makes a mistake if you eventually use the file on a
machine
> of the type in which it was created.

It's no good for a cgi-bin on a unix server!

> Other transfer programs are often disasters.

Again, even Fetch isn't even good enough to be "2nd rate." It seems to me
that if nobody has written fool proof FTP for the Mac yet, that it may not
EVER happen.

Please refute me! I'm an NT administrator, and that's my preferance, but I
really want to help my Mac clients be the best that they can be, and if we
can help each other learn, and maybe even fix some major issues, then I'm
all for it. (Besides, who wants to see BillyG at the top of the heap? Not
me! ;D) Not to mention the fact that it'd make *my* life a whole lot easier
if my PC wasn't the only machine in the house that can reliably make
large-scale site transfers!

--Jon S. Jaques
--jjaques@grovehillsys.com





***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch