Catch the output of PLINK.exe (PUTTY)

[PeterH]

Too bad. Gotta stop here. So, SC runret is Win8 and later only from now on.

[admin]

While I understand that this must be frustrating, cutting off the support for systems older than Win 8 can't be the final solution. In that case the command gets unusable (apart for your own personal scripts) because I don't think that 99% of the userbase migrated to Win 8 +

Sure. That's just my way to refuel my tanks. Stating in public that it's impossible gives my some magic extra power to solve a problem. Freaky, but I've done it before.

[bdeshi]

Stating in public that it's impossible gives my some magic extra power to solve a problem. Freaky, but I've done it before.

Oh, really? You can never write a complete CEA system within the year.

[admin]

Works only when I state it myself.

[bdeshi]

I can never write a complete CEA system within the year.

How about that?

[admin]

Black magic! What forces will it stir up?

[highend]

! SC runret: Issue on Windows XP, Vista, Windows 7. Fix attempt #6.

Gz! Works on Win 7 x64 (CP: 850 + 437). Do I need to test it with all other Win versions / bitnesses / codepages or can I safely assume that it'll work flawlessly?

[admin]

Ah, finally!

You know, there are thousands of examples for this in C++, C#, VB.net, VB whatever... I read and did everything and apparently nothing works (in < Win8)!

Now I simply ported that AHK code you posted (which is quite different from all those other examples in the web) and, bingo, it works!

Weird and beautiful!

PS: No need to test other versions (since you already tested the AHK way on them, right?)

[highend]

(since you already tested the AHK way on them, right?)

Yepp. In the meantime on Win 8 as well. Just to make sure xD

[admin]

I still cannot believe that runret never worked for < win8. Is that really so?

[highend]

It is...

14.10.0113 (this version got runret())
15.00.0500
16.00.0200

None of these versions produced an output on Win 7 x64

[TheQwerty]

runret worked on Win 7 under some conditions ever since it was introduced.

Using the same versions as highend and

Code: Select all

goto 'C:\';text runret('cmd /c dir');text runret('cmd /c chcp');

dir always returned something.
chcp did not.

OS: Windows 7 Professional (Service Pack 1), 64-bit (6.1)

System Locale ID: 1033 (en-US)
Thread Locale ID: 1033 (en-US)
Default ANSI Code Page: 1252 (ANSI - Latin I)
Active ANSI Code Page: 1252 (ANSI - Latin I)
Default OEM code page: 437 (OEM - United States)
Active OEM Code Page: 437 (OEM - United States)
Is DBCS Code Page: No

[admin]

It gets weirder and weirder.

Can other Win7 users confirm this? (Who knows what other factors play a role here...)

[PeterH]

OK: it's magic

As I see it: runret worked before, and I have used it sometimes.
It seems that there were a few commands making problems. The first was plink.exe, and the other chcp. While all others that I've tried seemed to have worked OK.

To me it seems that the originating program has different ways to output the data. And there seem to be some cases that led runret *not* to receive it as wanted.
It's not just the command - it's even what it does. For plink.exe normal output could not be received. But if you called plink.exe with wrong parameters the errormsg *was* received by runret.

Magic:

[LittleBiG]

Now runret with plink.exe works as expected. I am really happy, thanks. I have started to use this just recently, so I cannot say anything about the before.