net-ssh send_signal

[Guillaume Marcais]

Does Channel#send_signal work? The documentation says:

"Send the given signal to process on the other side of the channel. The
parameter should be one of the Channel::SIGxxx constants."

but a grep in the net-ssh gem directories reveals no such constants and

rb(main):134:0> Net::SSH::Connection::Channel.constants.grep(/^SIG/)
=> []

Is it an omission? Or is the signaling functionality not working at all?

Guillaume.

 

[Jamis Buck]

Guillaume,

It looks like an oversight. When I rewrote Net::SSH the last time, I
must have forgotten to port the constants over, too. At any rate,
they are simple enough. Just pass a string naming the signal you want
to send, chosen from this list:

ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2

Sorry about that,

Jamis

 

[Zach Dennis]

Guillaume,

It looks like an oversight. When I rewrote Net::SSH the last time, I
must have forgotten to port the constants over, too. At any rate, they
are simple enough. Just pass a string naming the signal you want to
send, chosen from this list:

ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2

Jamis,

Will this be added to the net-ssh cvs and put in next build? Is there
anyone actively working on net-ssh? I know you are busy in your job, but
is there anyone we should look to for upcoming releases or features? Thanks,

Zach

 

[Jamis Buck]

Will this be added to the net-ssh cvs and put in next build? Is
there anyone actively working on net-ssh? I know you are busy in
your job, but is there anyone we should look to for upcoming
releases or features? Thanks,

Zach,

I have been approached by someone who has expressed a desire to take
over maintenance of Net::SSH. However, he's been quite busy for the
last few months, too, and I'm not sure how soon he'll be able to
begin active development.

I won't speak for him, though. If/when he's ready, I'll let him speak
for himself.

- Jamis

 

[zdennis]

Zach,

I have been approached by someone who has expressed a desire to take
over maintenance of Net::SSH. However, he's been quite busy for the
last few months, too, and I'm not sure how soon he'll be able to begin
active development.

I won't speak for him, though. If/when he's ready, I'll let him speak
for himself.

Until that time can we expect any updates you make to be merged into the
net-ssh source, so when that person is able to take over issues that
have been fixed (or mentioned on the list) are incluced?

Thanks for everything Jamis, I love Net::SSH that is why I ask so much =)

Zach

 

[Jamis Buck]

Until that time can we expect any updates you make to be merged
into the net-ssh source, so when that person is able to take over
issues that have been fixed (or mentioned on the list) are incluced?

Thanks for everything Jamis, I love Net::SSH that is why I ask so
much =)

Any updates I make will be made to the Net::SSH source directly, and
committed to the repository. (Which, incidentally, is subversion now,
and is at http://svn.jamisbuck.org/net-ssh.)

However, I am not very likely to make any more updates (due to time
constraints, mostly), barring critical bugs that cannot be worked
around (and I don't believe there are many of those left). However,
if you have a feature or bug fix that you would like to see taken
care of ASAP, the quickest way is to fix it yourself and submit a
patch. I'm much more likely to spend the 15 minutes it takes to test
and apply a patch than the 1 or 2 hours it takes to fix something
myself.

And, while I'm on the topic of Net::SSH... My dream is for some noble
programmer to swoop in and rewrite Net::SSH for me. Why a rewrite?

1. The needle dependency is unnecessary. As has been demonstrated
repeatedly, a dependency injection framework is overkill for most
applications, and it certainly is for Net::SSH. Needle in Net::SSH is
mostly baggage that further complicates an already-complicated
framework.

2. The API is absolutely embarrassing. It was done completely
backwards. Instead of starting with a desired interface and working
back towards the implementation, I started with an implementation and
evolved the interface, which means it is currently confusing,
nonintuitive, and hostile.

3. Unit tests were tacked on after the fact, which means that instead
of testing what the library _ought_ to do, they test what the library
actually _does_. A subtle difference, perhaps, but significant.

Anyway, a fellow can dream.

- Jamis