For cancellation you run the actual operation in a goroutine and return
results on a channel.  You can then select on the Deadline from the context
and the returned result.  If the deadline hits, you just shut down the SSH
session.  Does that make sense?

    -Paul

On Tue, Sep 20, 2016 at 3:36 PM, Hiroaki Nakamura <hnaka...@gmail.com>
wrote:

> 2016-09-21 0:59 GMT+09:00 Paul Borman <bor...@google.com>:
> > I would suggest just putting your package out there and see how it is
> > received.  At some point, if it becomes the defacto package, moving it
> might
> > make sense.
>
> OK, I understood.
>
> >
> > I actually wrote an internal SCP package that works with a ssh
> multiplexer
> > built on top of crypto/ssh.  For various reasons, I am not in a position
> to
> > OpenSource the package.
>
> I hope your SCP package will be released as an OpenSource.
>
> >
> > It provides a NewSCP that returns an SCP object.  You provide NewSCP
> with a
> > configuration structure that specifies optional default timestamps,
> mode, if
> > -p should be used, and if Start or Shell should be used to make the
> session
> > (some SSH servers do not support exec mode (Start)).
> >
> > The SCP type only has 3 methods (and one is actually a convenience
> wrapper):
> >
> > func (*SCP) Send(ctx context.Context, dst string, srcs ...string) error
> >
> > Send sends the srcs to dst. If srcs has a length greater than 1, or any
> of
> > the srcs is a Directory, dst must reference a directory on the remote
> host.
> > Send returns any errors encountered. If an error is returned, it may
> contain
> > multiple errors. User Errors(err) to retrieve the list of errors.
> >
> > func (*SCP) Receive(ctx context.Context, src string, f func(*Incoming)
> > error) error
> >
> > Receive requests the directory or file src from the remote host. For each
> > directory and file in src, f is called with a populated Incoming
> structure.
> > If IsDir is not set then f must either populate W or return an error. In
> any
> > event, if f returns an error then that file or directory's transfer is
> > stopped. If the returned error is wrapped by Fatal{}, the entire SCP
> session
> > is shutdown.
> >
> > type Incoming struct {
> > Path    string      // Name of file on remote host
> > Mode    os.FileMode // Mode of the file on the remote host
> > MTime   time.Time   // Last modified time from the remote host
> > ATime   time.Time   // Last access time from the remote host
> > Length  int64       // Length of incoming file
> > IsDir   bool        // Set if receiving a directory
> > WErr    error       // Error encountered during write, if any
> > W       io.Writer   // Destination for read data
> > NoClose bool        // Do not close W when finished.
> > }
> >
> > Incoming is where to send information about a file or directory. When an
> > Incoming is provided to ReceiveFile, W must be set and IsDir must not be
> > set. If the set W also implements io.Closer, W.Close is called after the
> > fimal write to W, unless NoClose is set. NoClose is normally only set
> when
> > using a single io.Writer for all data (such as os.Stdout).
> >
> > The convenience function is:
> >
> > func (*SCP) ReceiveFile(ctx context.Context, in *Incoming, src string)
> error
> >
> > ReceiveFile requests the remote host send the file named src. ReceiveFile
> > writes the received contents to in.W. Path, Mode, MTime and ATime are set
> > prior to the first write to in.W. MTime and ATime may be the zero value
> for
> > time.Time if not provided by the remote host.
> >
> > If there is an error writing to in.W, in.WErr is set to the error.
> in.WErr
> > is only valid after ReceiveFile returns. If there is an error receiving
> the
> > file from the remote host, it is returned.
> >
> > You could easily imagine a wrapper that called Receive and provided an
> > internal function that did whatever needed to be done, or even a stock
> > function that can be passed to Receive.
> >
> > I hope this is helpful.
>
> Thanks for the spec about your SCP package.
> I think it is more general than mine.
>
> However most of my cases are copy a single file or a directory,
> so I think I'd keep my APIs for the moment.
>
> I added NewSCP and SCP
> https://github.com/hnakamur/go-scp/commit/b43795fc10ef52b02a76653b643fa5
> aabb7b85a7
>
> One thing I would like to add is the cancellation support using
> context.Context.
> However ssh.Run does not take a context.Context as an argument,
> so I don't know how to achieve that.
> https://godoc.org/golang.org/x/crypto/ssh#Session.Run
>
> Could you tell me how you implement the cancellation?
>
> Thanks,
> Hiroaki Nakamura
>
> >
> >     -Paul
> >
> > On Tue, Sep 20, 2016 at 6:47 AM, Hiroaki Nakamura <hnaka...@gmail.com>
> > wrote:
> >>
> >> Hi Paul,
> >> Thanks for your feedback!
> >>
> >> 2016-09-20 0:02 GMT+09:00 Paul Borman <bor...@google.com>:
> >> > Adding an scp package is a nice addition.
> >>
> >> I agree.
> >> Should I send a pull request to https://github.com/golang/crypto?
> >> If yes, what package? golang.org/x/crypto/scp or
> >> golang.org/x/crypto/ssh/scp?
> >>
> >> > You might want to consider simple names like:
> >> >
> >> > Send - Sends from []byte to file on remote host
> >> > SendDir - Send files in dir to a remote host
> >> > SendFile - Sends the contents of a file to the remote host
> >> > Fetch - Fetches the contents of a file on remote host into memory
> >> > FetchFile - Fetches a file from remote host into file on local host
> >> > FetchDir - Fetches the files in a directory from the remote host
> >> >
> >> > These would translate in code to names like scp.SendFile, which is
> >> > pretty
> >> > descriptive all by itself.
> >>
> >> Thanks for simple and descriptive function names.
> >> I renamed functions.
> >>
> >> https://github.com/hnakamur/go-scp/commit/
> 8cd6d9e5ab17187556e5efc3a666d29b4b561c78
> >>
> >> >
> >> > For the directory copy, it might be better to have a function return
> the
> >> > io.Writer to write the file to, rather than force the files into a
> >> > directory.  This would make it easy to keep the contents in memory,
> >> > change
> >> > file names, or whatever.
> >>
> >> Yes, I agree it might be better not to force the files in a directory.
> >> However I don't think having a function return the io.Writer will do
> >> since we need to read a reply for each scp protocol header or body.
> >>
> >> I had read the article below and the openssh source code and
> >> implemented my scp package https://github.com/hnakamur/go-scp.
> >>
> >> "How the SCP protocol works (Jan Pechanec's weblog)"
> >> https://blogs.oracle.com/janp/entry/how_the_scp_protocol_works
> >>
> >> I built two structs sourceProtocol and sinkProtocol
> >> https://github.com/hnakamur/go-scp/blob/master/protocol.go
> >>
> >> I had thought to export these structs or make interfaces for that.
> >> However the implementation of two functions SendDir and FetchDir
> >> which using these structs become somewhat complex.
> >>
> >>
> >> https://github.com/hnakamur/go-scp/blob/8cd6d9e5ab17187556e5efc3a666d2
> 9b4b561c78/source.go#L81-L175
> >>
> >> https://github.com/hnakamur/go-scp/blob/8cd6d9e5ab17187556e5efc3a666d2
> 9b4b561c78/sink.go#L111-L223
> >>
> >> So I was not confident about exporting sourceProtocol and sinkProtocol,
> >> and I did not export them at the time.
> >>
> >> If we can define structs, functions or interfaces which are easy to use,
> >> I'm glad to export them.
> >>
> >> Do you have an idea about such structs, functions or interfaces?
> >> Thanks!
> >>
> >> Hiroaki Nakamura
> >>
> >> >
> >> > On Fri, Sep 16, 2016 at 9:41 AM, Hiroaki Nakamura <hnaka...@gmail.com
> >
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I noticed the golang.org/x/crypto/ssh package exists, but the scp
> >> >> package does not.
> >> >> So I wrote a scp client library in go.
> >> >> https://github.com/hnakamur/go-scp
> >> >>
> >> >> I also wrote a sshd server just usable for testing go-scp.
> >> >> https://github.com/hnakamur/go-sshd
> >> >>
> >> >> Right now, go-scp only exports high level functions which are
> supposed
> >> >> to be easy to use.
> >> >> https://godoc.org/github.com/hnakamur/go-scp
> >> >>
> >> >> However I wonder if there APIs can be improved. For example,
> >> >> better function names and better arguments.
> >> >>
> >> >> Could you tell me what you think?
> >> >> Thanks!
> >> >>
> >> >> Hiroaki Nakamura
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google
> >> >> Groups
> >> >> "golang-nuts" group.
> >> >> To unsubscribe from this group and stop receiving emails from it,
> send
> >> >> an
> >> >> email to golang-nuts+unsubscr...@googlegroups.com.
> >> >> For more options, visit https://groups.google.com/d/optout.
> >> >
> >> >
> >
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to