On 8/3/2011 10:30 AM, Brian Mathis wrote:
>
>>> to not use an ftp client at all and instead use a scripting language,
>>> such as perl or python, that has libraries meant for talking to these
>>> protocols. Their man pages pretty much show you how even if you don't
>>> know the language.
>>
>> Wait - isn't that an alternative technology?!?
>
>
> No it's not, and you're making a stupid argument. Clearly there is a
> difference between using a different client versus changing the entire
> protocol stack across all systems it's being used for. Using a better
> client mechanism involves maybe an hour or so worth of work, while
> changing the entire protocol you're using requires changing every
> service on every server in every company you might be interfacing
> with. One of those is easy to do, the other one is likely impossible.
That might be true, or it might not. If you already have an ssh service
running, you don't have to set up something else to run rsync or scp (or
sftp, I think...).
> I find it strange and annoying that so many times the answers to
> questions like the OP's so often and so clearly miss the mark, as if
> no one here understands what's actually involved in implementing a new
> protocol stack across an enterprise or between enterprises.
Which is why most places end up running stuff over ssh as a transport.
>>> The questionable thing is not using entrenched protocols, but using
>>> old methods like redirecting ftp commands via STDIN into a client to
>>> control it.
>>
>> /bin/sh is an "old method". TCP is pretty ancient, as well. For that matter,
>> UNIX is REALLY ancient. Yet somehow, they are not only still useful, but
>> highly relevant. Wheels are also old technology!
Which is why people like unix/shells/pipes, where every well designed
program includes the ability to use all the others.
> Redirecting commands into an ftp client (and, btw, I don't know if the
> OP is doing this, but it's still amazingly common) is a provably bad
> "old" method of doing things. You cannot deal with error conditions
> or anything else that might come up. Using a scripting
> language/library allows you to deal with these obvious problems.
As does running a program that is better-designed to do the job.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
