Вывод программы проиграл при передаче через PsExec

Хорошо, я ' Я думал об этом на выходных, и, поскольку вы перепрыгиваете с машины на машину, мне интересно, может быть, есть проблема с CharSet? Может быть, он съедает строку в первый раз и имеет дело с другой проблемой кодовой страницы или набора символов? В Java обычно используются 16-битные символы, а в современных Windows - 8-битные с кодовыми страницами или utf-8.

Есть ли вероятность, что локальные и удаленные машины имеют разные наборы символов по умолчанию? Если вы отправляете локализованные данные по сети, они могут работать некорректно.

PsExec is eating the output. Next interesting thing might be where it's eating the output. You could check this by getting a copy of Wireshark and checking whether the output in question is traversing the network or not. If it's not, then it's being eaten on the remote side. If it is, it's being eaten locally.

Not that I'm really sure where to go from there, but collecting more information certainly seems like a good path to be following...

Может быть, вы могли бы попробовать передать копию ввода вашим слушателям:

 public void fireInputRecieved(String input) {

    if(input.equals("quit"))
    exit = true;

    String inputCopy = new String(input);
    System.out.println("Input string has made it to fireInputRecieved: "
        + input);



    for(int index = 0; index < listeners.size(); index++)
        listeners.get(index).inputRecieved(inputCopy);
}

У меня были аналогичные проблемы со слушателями, когда переданная переменная заканчивалась пустой, если я не передал ее явную копию.

У меня не обязательно есть ответ, но некоторые комментарии могут оказаться полезными.

• Идея «передать копию» не должна иметь значения, поскольку в вашем выводе строка успешно печатается дважды перед ошибкой, а затем снова выполняется успешно.
• автоматическая очистка также не имеет значения, как вы уже упоминали
• Предложение Нико имеет некоторые достоинства в диагностических целях. В сочетании с предложением Марка это заставляет меня задаться вопросом, нет ли где-нибудь невидимых управляющих персонажей. Что, если вы напечатали байтовые значения символов в качестве диагностического шага?
• Вы знаете , что это значение «Test» (по крайней мере, в выходных данных, которые вы нам предоставили). Что произойдет, если вы передадите «Test» непосредственно провалившемуся оператору printLn?
• В подобных ситуациях вы хотите получить как можно больше информации. Вставляйте точки останова и анализируйте символы. Отправьте байты в файлы и откройте их в шестнадцатеричных редакторах. Делайте все возможное, чтобы отслеживать вещи как можно точнее и точнее.
• Придумайте странные тестовые сценарии и попробуйте их, даже если они не могут помочь. Никогда не знаешь, какая хорошая идея могла бы возникнуть, анализируя результаты безнадежной идеи.

При запуске psexec я вижу, что он порождает дочернее окно для выполнения работы, но не возвращает вывод этой программы в окно консоли. Я бы посоветовал использовать WMI или какую-либо форму API-интерфейса процессов Windows, чтобы получить уровень контроля, которого вам не хватает с помощью psexec. Несомненно, у java есть эквивалент .Net классу System.Diagnotics.Process.

Is System.out not configured for autoflush? After the first print try System.out.flush() and see if the first line appears without more lines being printed.

(oh yeah, seriously, it is "RECEIVED", not "RECIEVED".)

I'd guess that there is a bogus byte in there prefacing the T. According to JavaDocs, an InputStreamReader will read one or more bytes, and decode them into characters.

You could have an escape sequence or spurious byte in there, masquerading as a multibyte character.

Quick check - see if "current" is ever > 128 or < 33.

What if you used a CharArrayReader to get individual bytes, without any charset translation?

The theory is that during the first attempt to output the String using println, it's sending an escape character of some sort, eating the rest of the string. During later prints, either Java or the network pipe are handling or removing it, since it previously got that escape sequence, perhaps changing the handling in some way.

As an unrelated nit, sb.toString() returns a new String, so it's unnecessary to call "new String(sb.toString())"

Как вы выполняете PsExec? Я подозреваю, что это какой-то код внутри PsExec, который на самом деле выполняет подавление эха, возможно, в целях защиты пароля. Один из способов проверить эту гипотезу - это изменить этот код:

    System.out.println("Outputting it cleanly to standard out: ");
    System.out.println(input);
    System.out.println("Outputting it cleanly to standard out again: ");
    System.out.println(input);

на этот:

    System.out.println("Outputting it cleanly to standard out: ");
    System.out.print(' ');
    System.out.println(input);
    System.out.println("Outputting it cleanly to standard out again: ");
    System.out.println(input);

... таким образом, вывод будет (если я прав):

Outputting it cleanly to standard out:
 Test
Outputting it cleanly to standard out again:
Test
Finished example outputs of input: Test

В частности, заметно, что очевидно -suppressed line - это первая строка, состоящая исключительно из Test - это именно тот текст, который вы только что отправили в удаленную систему. Похоже, PsExec пытается подавить удаленную систему, которая повторяет свой ввод в дополнение к созданию собственного вывода.

Возможно, пароль пользователя на удаленной машине Test ? Вы используете PsExec? s -p параметр? Вы указываете -i ?