[Discuss] SCP from STDIN: "-t" option undocumented?

[gaf at blu.org (Jerry Feldman)]

I think in this case, possibly the reasoning was that this is an
internal usage and they don't want it to be used other than as the
client end of the connection.

On 12/23/2011 05:58 PM, Jon "maddog" Hall wrote:
> As we have all experienced, once an API is published, it is a lot harder
> to get rid of it.  In commercial systems you have to "retire" it.
>
> A reason for undocumented APIs is that the creator of the command needs
> the API to do something ("scratch an itch"), but did not like the way
> they had programmed it and meant to go back later and re-design the
> functionality, so did not want people (or at least clueless people) to
> start using that functionality in that particular way.
>
> Another reason was that the creator of the command wanted to create an
> unpublished interface so they could try out the functionality in large
> scale without committing to it for future releases.
>
> Or it could simply be that they created it and forgot to document it.
>
> md
>
> On Fri, 2011-12-23 at 17:31 -0500, John Abreau wrote:
>> In my case, I had a passwordless ssh key, and a validate-rsync script
>> to use in the key's "command=" prefix in the authorized_keys file.
>> I wanted to allow the same key to accept scp as well as rsync.
>> I discovered the -t option when I had the validate-rsync script write
>> the $SSH_ORIGINAL_COMMAND to a logfile in order to determine
>> how scp works behind the scenes.
>>
>>
>>
>> On Fri, Dec 23, 2011 at 2:59 PM, Jerry Feldman <gaf at blu.org> wrote:
>>
>>> The issue IMHO, is the lack of documentation for the -t option. I feel
>>> that every interface should be documented. As a programmer I am used toJohn Abreau <jabr at blu.org>
>>> APIs. Historically, my colleagues find hidden APIs, and use them for
>>> either because they are there or because they might be more efficient.
>> ....
>>> How many programs have been written to use undocumented APIs
>>> only to crash when the vendor changes the API without notice.
>>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90