Current working directory

[dca00]

Could you please double-check the following:
When I issue pwd command, it prints my current working directory, for instance /root.
When I then issue cd .config where .config is an existing sub-directory of /root it completes successfully.
When I then issue ls it lists the contents of /root instead of the contents of /root/.config. It looks like the change of directory is not retained between issuing RunCommand() within the same connection. I verified that the connection is not dropped between commands, so there is no reason for the working directory to reset to the user's default.

[dca00]

Any luck looking into it or any tips on how to work around it?

[darkoperator]

Use a shellstream Sent from my iPhoneOn Oct 9, 2022, at 12:21 PM, dca00 ***@***.***> wrote: Any luck looking into it or any tips on how to work around it? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[darkoperator]

Runcommand uses the same API call as Plink, it does not maintain state since it a commection is not a terminal shell, you need to use a shell stream, write the command to the stream amd read from the stream the results

[dca00]

Thanks for your suggestion!
Tried it out. I am on a different system, so going by memory:

Created a shellstream.
Created a streamreader and a streamwriter from the stream.
Read to end. Received nothing.
Delayed 200 ms. Read to end again. Received a welcome prompt.
Delayed 200 ms again. Read to end. Received user's command prompt [root@localhost]# (or this could have been after I wrote a command)
Wrote-line my command.
Delayed 200 ms.
Read to end. Received nothing (or command prompt). The sensation of being ignored is overwhelming at this point 8\.

Tried it in sync and async variants. No dice. This thing is staring down at me with like 'let's see what you are made of, puny mortal' stare.

This is the weirdest implementation that I had ever seen. None of my experience from 15 years of using streams in .NET seem to apply.
What am I doing wrong?

And I do badly need this to work because execcommand assumes an 80 column-wide terminal and truncates data in the output of some commands. This library leaves lots to be desired, to be quite honest.

[dca00]

Ah, nevermind! Figures, it needs a flush. "I think she's gonna do that. Don't you, pal?'

Why for chrissake do we need a flush on an inherently non-caching stream? It's not that it's a buffered filesystem stream for crying out loud. Could we push several commands into it and hope for output? Just asking.

Now, there is another problem that has me totally stumped. I had set term height to 50 beforehand but I am only getting 19 lines of output out of 22. Where's the 3 missing ones? An no, it's not paging.

[dca00]

Regarding the 3 missing lines, figures .DataAvailable alone cannot be trusted. It becomes weirder by the second:

Initially, upon having issued a command, reader.Peek() = -1 and .DataAvailable = true.
After having read those 19 lines, .DataAvailable = false but reader.Peek = whatever next char it is.

So, both have to be used. It would be amusing to learn the reason for this.