Почему cl.exe не генерирует какой-либо вывод, когда я вызываю его из Perl?

У меня возникла странная проблема с запуском cl.exe, который меня озадачил. В большом VS2008 решении, состоящем из проектов C/C++, у меня есть один проект, который запускает некоторые скрипты для выполнения дополнительной обработки. Проект состоит из события предварительной сборки, которое вызывает сценарий Perl (ActiveState Perl находится на машине). Этот скрипт Perl вызывает cl.exe с /E для генерации предварительно обработанного вывода, который перенаправляется в файл. Строка в Perl выглядит следующим образом:Почему cl.exe не генерирует какой-либо вывод, когда я вызываю его из Perl?

my $foo = `"\path\to\cl.exe" @args.rsp >out.txt 2>err.txt`;

args.rsp представляет собой обычный текстовый файл, который содержит кучу командной строки арг для cl.exe, в том числе /E, чтобы получить выход предварительного процессора на стандартный вывод.

Эта точная командная строка работает, как ожидается, при запуске из командной строки VS2008. Построение проекта также отлично работает на моей машине с Windows XP. Однако в моем новом окне Windows 7, когда я создаю проект, out.txt заканчивается пустым. Я также должен добавить, что на некоторых из моих коровских ящиков Windows 7 он отлично работает, а на некоторых других - нет.

Очевидно, что существует какая-то разница в конфигурации, но я не понимаю, что это может быть. Мы проверили соответствующие версии VS2008 SP1 и ActiveState Perl. Я пробовал множество обходных путей внутри скрипта perl - используя system() вместо обратных ссылок, используя cl.exe /P для вывода в файл, а затем перемещения файла (файл пуст), отключая переменную окружения VS_UNICODE_OUTPUT (без эффекта). Ничто не изменило поведение - вывод создается, когда командная строка запускается вручную, но не тогда, когда она запускается внутри события предварительной сборки для этого проекта.

Любые идеи о том, какая проблема конфигурации может быть причиной этого? Я довольно много из возможностей преследовать.

источник

2010-01-07 Stephen DiVerdi

Я вижу, что вы решили проблему, но я удивлен, поскольку вам кажется, что вам не хватает удвоенной обратной косой черты на пути - или это просто артефакт для форматирования SO? –

Звучит как вопрос ACL для меня. Вы можете изменить окна на проблемы с доступом к журналу, а затем проверить журнал событий, чтобы узнать, какой пользователь получает отказ в доступе.

Я считаю, что настройка находится в локальной политике | Политика аудита | Аудит доступа к объекту

источник

2010-01-07 19:53:04 Hogan

Хм, спасибо! Я забыл упомянуть, что в этот момент я отключил UAC и установил devenv.exe, cl.exe и perl.exe для запуска в качестве администратора (это из учетной записи с правами администратора). Но я посмотрю, смогу ли я немного обмануть ACL и получить дополнительную информацию. –

Хмм, я проверял ошибки и успехи для моего пользователя для соответствующих выходных файлов (фактически все файлы в выходном каталоге, так как я удаляю, а затем воссоздавая файл, а настройки аудита теряются). Я вижу много успехов в аудите для доступа к объектам, но никаких сбоев. Я никогда не играл с аудитом раньше, так что, возможно, я делаю что-то неправильно ...: -/ –

Я всегда настраивал его для проверки всех файлов/каталогов, потому что вы никогда не знаете, где создается файл (может быть случайное местоположение tmp.) – Hogan

Проверьте код выхода программы. Вы можете создать свое исполняемое имя портативным способом, используя что-то вроде File::Spec. Кроме того, убедитесь, что @args не интерполируется. Вы можете распечатать свою командную строку перед выполнением, чтобы проверить, хотите ли вы этого. Что осталось от вашего файла err.txt?

источник

2010-01-07 20:01:05

Код выхода cl.exe является успешным, как и perl-скрипт. Я напечатал командную строку как через perl println, так и через 'echo ...' и проверил, что @args правильно передается. err.txt всегда пуст. Спасибо за предложения! Я только что взламываю это на несколько дней. :-) –

Вау, решение этого оказалось намного более странным, чем я ожидал. Машина, над которой я работаю (и другие сотрудники, которые также испытывают проблему), - это Mac Pro с установленной программой bootcamp и Windows 7. Это заставляет C: иметь Windows-диск и E: иметь Mac-диск. Это вызывает проблему, потому что событие pre-build имеет пару строк, которые проверяют каждую букву диска, чтобы увидеть, есть ли там диск, а если есть, добавляет X: \ Perl \ bin в путь. Даже если E: \ Perl \ bin не существует, он добавляется к пути. Позже скрипт perl запускается, а затем вызывает cl.exe, и по какой-то причине наличие каталога в Mac-диске приводит к сбою cl.exe. Зачем? Понятия не имею. Во всяком случае, удаление каталога диска Mac из пути устраняет проблему!

Спасибо за ваши глаза.

источник

2010-01-07 22:11:18

Почему cl.exe не генерирует какой-либо вывод, когда я вызываю его из Perl?

ответ

Смежные вопросы