I don¹t buy it, because sftp is also based on ssh, yet it does what it¹s
documented to do. And the argument that you have sftp to do binary transfers
doesn¹t hold water either, because the two commands are used for very
different reasons.
Translating the command on the ssh line is the correct thing to do, but
munging all the data that the command acted on is not. It¹s a huge, and
incorrect, assumption that everything you might want to copy will be text.
Java class files are a prime example. These get ³scp²ed around commonly in
the real world, and yet this ssh implementation ignores that and corrupts
the file when it is transferred.
The scp command is literally corrupting the data it is transferring, plain
and simple. I ³know² that scp is a binary transfer, because that¹s the way
it¹s documented in Unix. But if I try to use it on USS, it corrupts my
file... ANY file, because I expect ascii files to be ascii when I use scp to
copy them; it¹s a binary transfer. It is supposed to be a secure,
cross-system implementation of the cp command. Where is it documented that
cp will translate files? It¹s not.
You can only use the USS scp command to handle text files, and how long has
it been since we only dealt with text files? Back into the 60¹s? If ever?
USS scp is a useless command, because the results will not mirror what you¹d
expect on other Posix compliant systems.
--
.~. Robert P. Nix Mayo Foundation
/V\ RO-OC-1-13 200 First Street SW
/ ( ) \ 507-284-0844 Rochester, MN 55905
^^-^^ -----
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
> From: Richard Troth <[EMAIL PROTECTED]>
>
> The problem (or "feature") is that SCP is layered on SSH, which itself
> is a GOOD thing. SSH performs A/E translation because its main purpose in
> life is to provide command access (whether batched or interactive). So
> as annoying as the A/E astonishment is, for me its an old story. There
> are so many other points where text or binary must be handled differently
> ... but this isn't necessarily helping.
>
> Consider this:
>
> ssh remotehost tar cf - /something | tar xf -
>
> will flat out not work when hitting z/OS (USS) or when issued to an ASCII
> system from there. SCP at least gets the content across intact.
> (Translated, yes, but intact.)
>
> A little pipe-think would resolve the TAR issue. Dunno if it would help
> in the SCP case. (EG: convert binary to base64 before transport, then
> restore base64 back to its binary form on the receiving end.)
>
> -- R;
>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
