On Tue, Aug 2, 2011 at 10:19 PM, Benjamin Smith <lists at benjamindsmith.com> wrote: > On Tuesday, August 02, 2011 04:06:53 PM Brian Mathis wrote: >> Instead of suggesting alternate technologies, > > Ok, so this implies that suggesting alternatives is bad... > >> it should be suggested >> 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. 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. >> 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! See above, re: stupid argument. If your objection is to the use of the word "old" as opposed to something like "error prone", please perform 's/old/error prone/g' in your head and save us the pixels. P.S. Something becomes "old" when it's been replaced by a newer, better way of doing things, not simply because of age. 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. > There are often situations that have special needs that alternatives don't > accommodate. For example, a general purpose tool (such as tcp wrappers in a > scripting environment) often don't give you the fine level of control that > you may need for special needs. Such as, for instance, the web-based product > that adds an optional http header to indicate an error condition. Tools like > wget or curl don't always allow access to the options needed to access this > and so "sending stdout thru a pipe to an FTP client" might be preferable. > > I've been around the block long enough to know that those who are most > certain they have the right answer right away are usually those least likely > to have it. Science backs this conclusion up, it's called the Dunning-Kruger > effect. -☙ Brian Mathis ❧-