Return-Path: <danson@germane-software.com>
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 19953 invoked from network); 20 Feb 2003 22:49:33 -0000
Received: from unknown (HELO germane-software.com) (198.36.168.17)
  by daedalus.apache.org with SMTP; 20 Feb 2003 22:49:33 -0000
Received: (qmail 30751 invoked from network); 20 Feb 2003 22:49:00 -0000
Received: from unknown (HELO germane-software.com) (63.96.184.251)
  by 198.36.168.17 with SMTP; 20 Feb 2003 22:49:00 -0000
Message-ID: <3E555B56.60005@germane-software.com>
Date: Thu, 20 Feb 2003 14:48:54 -0800
From: Dale Anson <danson@germane-software.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: SSH Tasks
References: 
 <51C603B9AB4696408D7273AA133734AC02B23865@ljcms002.prod.vectorscm.com>
 <01eb01c2d90b$c1145cc0$030200c0@DJ0X820J>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Yes, the ssh task that I wrote does not follow the telnet task 
convention. It is a fairly simple task and does not do anything with the 
response other than log it. I can think of situations where this would 
be useful, and similarity with other tasks is always desirable.  
Getting, parsing, and responding to the server response is doable, but 
not implemented.

Also I would imagine that the scp task should model the copy task, which 
is does not, at this point. None of the fileset/filterset/mapper stuff 
has been done. The posts on this list from "Joe Consumer" look like the 
scp task he's done is further along in implementing these features, and 
I believe he has also based his task on jsch. He also mentioned 
something about key stores being implemented, which Robert Anderson has 
said is a necessary feature.

Let me know how I can help move forward with this.

Dale Anson



Antoine Levy-Lambert wrote:

>The <read> <write> interactivity could be used to be able to respond to
>different situations like
>    ls -l foo
>    ls: foo: No such file or directory
>    ...
>   or
>
>   ls -l foo
>   -rwxr-xr-x    1 Administ Kein         1538 Feb 20 19:03 foo
>
>It is true that ssh does not need to be interactive.
>The type of "dialog" I am referring to is better handled by a shell script
>or an ant build file at the remote end.
>
>It looks like the telnet task needs <read><write> for the login; this is not
>the case for ssh.
>
>Antoine
>----- Original Message -----
>From: "Anderson, Rob H - VSCM" <Anderson.Rob@vectorscm.com>
>To: "'Ant Developers List'" <dev@ant.apache.org>
>Sent: Thursday, February 20, 2003 6:42 PM
>Subject: RE: SSH Tasks
>
>
>  
>
>>My comments (RA>) below. I encourage others to chime in.
>>
>>-----Original Message-----
>>From: Stefan Bodewig [mailto:bodewig@apache.org]
>>Sent: Thursday, February 20, 2003 9:12 AM
>>To: dev@ant.apache.org
>>Subject: Re: SSH Tasks
>>
>>
>>On Thu, 20 Feb 2003, Rob H. Anderson <Anderson.Rob@vectorscm.com>
>>wrote:
>>
>>    
>>
>>>The ssh task is different from the telnet task in that is not meant
>>>to handle an interactive shell session, beyond the password
>>>authentication.
>>>      
>>>
>>Why not?
>>
>>RA> Because there is no need to interact with the shell.
>>
>>    
>>
>>>It is meant to provide the ability to execute commands remotely as
>>>if you were running ssh as follows:
>>>
>>>ssh username@hostname 'command arg'
>>>      
>>>
>>Which could be seen as a degenerate case with just a single <write>.
>>
>>RA> Sure. And the this feature could have been left out of ssh, forcing
>>    
>>
>you
>  
>
>>to interact with
>>RA> the shell. Don't you think it is unnecessary to force interactivity
>>where none is needed?
>>RA> Other than "consistency with the telnet command", what other value
>>    
>>
>would
>  
>
>><read>/<write> add?
>>
>>    
>>
>>>This sort of thing would be much more difficult to program (and
>>>maintain) as well.
>>>      
>>>
>>I must admit that I'm not familiar with the jsch code at all, so I
>>can't comment on this.
>>
>>
>>Stefan
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail: dev-help@ant.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>>For additional commands, e-mail: dev-help@ant.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>For additional commands, e-mail: dev-help@ant.apache.org
>
>  
>