PHP DM Gate v0.9 » ShellExecute + cscript + перенаправление вывода

AlekVolsk (04.06.13 23:16) [0]

Добрый день. Где я накосячил?
Win8x64, Delphi XE3
Есть скрипт на vbs, выполняющий определенную работу и выводящий результат на экран.
если я в командной строке наберу
cscript.exe myscript.vbs > result.txt

то в папке со скриптом появиться файл result.txt, однако, если я пытаюсь выполнить команду программно, то ничего не происходит:
var
ScriptFile, ResultFile: string;
begin
ScriptFile := GetEnvironmentVariable('TMP') + '\cdump.vbs';
ResultFile := GetEnvironmentVariable('TMP') + '\cdump.txt';
ShellExecute(0, 'open', PChar('cscript.exe'), PChar('\"' + ScriptFile + '\" > \"' + ResultFile + '\"'), nil, 0);
end;

причем код выполняется от имени админа, где я накосячил?

<Цитата>
AlekVolsk (04.06.13 23:36) [1]

пробовал внутри скрипта прописать
set FSO=CreateObject("Scripting.FileSystemObject")
set file =FSO.CreateTextFile("cdump.txt")
file.WriteLine("test")
file.Close

бесполезно, такое ощущение, что скрипт вообще не запускается, хотя cscript в памяти на мгновение появляется

<Цитата>
Eraser © (05.06.13 03:40) [2]

> AlekVolsk (04.06.13 23:16)

ShellExecute это не cmd.exe

<Цитата>
AlekVolsk (05.06.13 07:17) [3]

Пуск->Выполнить тоже не cmd.exe, и командная строка в тотале также cmd.exe не является, однако там все работает, а ShellExecute - нет :(

<Цитата>
брат Птибурдукова (05.06.13 15:10) [4]

То, что в некоторых случаях > работает как перенаправление потока — не более чем соглашение. Как уже сказали, нужно выполнять
%comspec% /c cscript "ScriptFile" > "ResultFile"

, тогда сработает. Или переписать скрипт, чтобы принимал имя выходного файла и действовал сообразно.

<Цитата>
AlekVolsk (05.06.13 18:44) [5]

>[4]
не работает, похоже, cscript это не консольное приложение, во всяком случае ряд функций генерит вполне реальный gui

<Цитата>
AlekVolsk (06.06.13 00:11) [6]

выяснил следующее.
в скрипте есть код:

Set WshShell = CreateObject("WScript.Shell")
regKey = "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\"
DigitalProductId = WshShell.RegRead(regKey & "DigitalProductId")

так вот, из проводника все запускается нормально, при попытке открыть программно выдает в консоль:
WshShell.RegRead: Не удается открыть для чтения раздел реестра "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId".

Не хватает прав? каких?

<Цитата>
брат Птибурдукова (06.06.13 11:12) [7]

> Не хватает прав? каких?
Мне кажется, проблема скорее с битностью. Из эксплорера запускается 64-битный cscript, программно — 32-битный, соответственно, смотрят в разные ветки реестра.

<Цитата>
AlekVolsk (06.06.13 14:17) [8]

возможно, допускаю. а как в таком случае задать права доступа к реестру из скрипта, аналогично Regystry.Access := KEY_READ or KEW_WOW64_64KEY; в delphi (понимаю, что вопрос уже не по delphi, но все же, а вдруг кто знает?)?

<Цитата>
брат Птибурдукова (06.06.13 16:20) [9]

ну я бы попробовал принудительно запускать 64-битный cscript, который из эксплорера запускается

<Цитата>
AlekVolsk (06.06.13 18:54) [10]

помогло, запускал
%systemroot%\sysnative\cscript "ScriptFile"

.
огромная благодарность за помощь!

<Цитата>
Алканавт расправил плечи (06.06.13 19:50) [11]

> %systemroot%\sysnative\cscript
Это "псевдокод" или особенность восьмой винды? У меня под семёркой никакого sysnative нету, надо бы поосторожней.

<Цитата>
AlekVolsk (06.06.13 20:25) [12]

да, псевдокод, поддержка которого реализована самой виндой. это особенность 64-разрядной винды для 32-разрядных приложений:
%systemroot%\sysnative\ - 64-разрядные библиотеки, по факту лежащие в %systemroot%\system32\
%systemroot%\system32\ - 32-разрядные библиотеки, по факту лежащие в %systemroot%\SysWOW64\
источник: журнал blasepascalmagazine #4, статья Александра Алексеева "В ожидании x64: WOW64"

<Цитата>