Subject: Re: shell exec and parseing

Re: shell exec and parseing

From: Peter Stuge <>
Date: Fri, 29 Jan 2010 21:57:44 +0100

A. Mark wrote:
> Thanks for your input Peter !

You're welcome.

> > Sorry, but this is totally off-topic here.
> I realize that, except that this is concerning a shell running from
> the libss2 library

The shell is running on the server side - libssh2 has nothing to do
with the shell at all. All the stuff dealing with the shell is either
in your app or in the remote sshd.

> and I wasn't sure if there was anything in the lib to handle this
> kind of issue. I guess the answer is no and thus I'm on my own.

Correct. There isn't and quite likely will never be anything in
libssh2 to deal with a remote shell because again, shells are *user*
interfaces, and libssh2 is an *application* library. The remote shell
basically does not offer any way for *applications* to interact with
it. My best advice is to come up with another way to solve your
problem. /bin/sh has no place in a generic, reliable solution.

> > interface" - which means it is such a waste of time to try to
> > "remote control" it from another program.
> I'm not trying to remote control the shell, I'm just trying to see
> if i can easily check process status of my app running in the
> shell, but I understand your point.

What do you mean by process status?

Oh, and how can you be sure that the remote server even *supports*
processes? You might be talking to an SSHD which doesn't have any
such concept.

What exactly do you want to do?

If you can assume that the remote end will always be Linux you can of
course interface with /proc on the remote host in a separate channel.
All you need then is the pid of the process in the first channel,
which you might be able to retrieve easily. (SSH does not offer any
way to do it though, you have to do it on your own.)

> > you could have one SSH channel and exec per command
> I have been using this method for a while now and it works ok,
> except that starting and closing the channel seems to take a lot
> longer than having a shell and just issuing commands, so the latter
> seems like a more stable alternative. (Especially if i have to
> start the app many times over in succession.)

The latter is extremely unstable, because you are most likely making
a great many assumptions about the shell on the remote server - while
the former is extremely stable, because it makes *NO* assumptions
about shells on the remote server. The former method only needs to
rely on SSH protocol.

It's quite possible that there are easy ways to increase performance
using the former method. libssh2 has sub-optimal performance in many
cases, so there might be a fix if you look into this some more.

> > Well, it can at least be made a little bit easier than that. :)
> > Read into a buffer and try using sscanf instead.
> Yes, I've tried this approach but for some reason I could not get
> it to work as I was loosing parts of the messages every time, but
> I'll try again now that I know it's doable.

It should certainly work. If you run into trouble please reproduce
the problem with a minimal C program and post that program to the
list. If others can easily reproduce your problem you can usually get
expert advice and very fast solutions - sometimes within minutes. But
the flip side is that if you do too little to help others then you'll
get no help at all.

> Thanks for taking the time to answer my questions Peter!

Again - you're welcome. I hope you can find a robust solution with
libssh2, I'm just convinced that you should try to avoid the shell.

Received on 2010-01-29