Подтвердить что ты не робот

Что может привести к сбою системных вызовов Perl?

Небольшой запрос: я каждый день читаю вопросы о переполнении Perl Overlack и отвечаю/вносим, ​​где могу; сегодня мне нужна помощь сообщества!

Настройка Perl: я запускаю Active Perl 5.8.8 для Windows. Установка выполняется на локальном диске сервера нашего отдела, который также используется в сети. Все пользователи отдела используют Perl на своих ПК, указывая на установленный в сети Perl. Это проработало много лет и не вызывает проблем, но это часть информации, необходимая для понимания проблемы.

Сервер, о котором идет речь, также является нашим сервером "cron" (Scheduled Task), который обрабатывает множество задач автоматизации. Внезапно на прошлой неделе системные вызовы в сценариях Perl (на сервере) начали сбой (подробнее см. Ниже). Сначала я подозревал поврежденную установку Perl, но все клиентские ПК все еще могут запускать одни и те же скрипты Perl без каких-либо проблем, что заставляет меня думать об этом как о сервере. Я перезагрузил сервер дважды, и проблема остается постоянной, поэтому мне нужна помощь!

Вот несколько примеров различного способа отказа системных вызовов, сведенных к однострочным Perl:

% perl -e "system('dir')"

Это должно печатать список "dir", но вместо этого открывается под-оболочка. Если я нахожу "exit", я могу выйти из под-оболочки, и я вернусь в исходную оболочку (подтвержденную проверкой истории оболочки с помощью клавиши со стрелкой ВВЕРХ).

% perl -e "print `dir`"

Это действительно зависает. Ничего не происходит. Если я Ctrl-C, чтобы убить процесс, я получаю сообщение "Завершение сигнала SIGINT (2)", и возвращается сообщение DOS. Но любые будущие команды в подсказке DOS (даже при нажатии ENTER) вызывают ошибку "Процесс пытался записать в несуществующий канал". Вам нужно выйти из приглашения DOS, поскольку оно эффективно бесполезно.

Последний пример:

% perl -e "system('Z:/Scripts/rebuild.pl')"

'ebuild.pl' не распознается как внутренняя или внешняя команда, оперативной программы или командного файла.

В этом случае Perl переключает обратные косые черты (/) на DOS/Windows back-slashes(), которые он отлично справлялся годами. Но Perl интерпретирует "\ r" в начале файла "rebuild.pl" как возврат каретки (я думаю) и ищет оставшийся "ebuild.pl". Вызов других имен сценариев, чьи символы не могут быть неверно истолкованы, как результат, приводит к зависанию (если вы используете обратные такты) открытых подклассов (для вызовов system()).

Я не просто озадачен этим - я в отчаянии! Наши рабочие места сервера "cron" бесполезны прямо сейчас, так как мы используем много системных вызовов.

Опять же, я не думаю, что это коррумпированная установка Perl, так как пользователи сети могут нормально работать. Итак, что может произойти на отдельной машине (не привязанной к самой установке Perl), которая может привести к сбою системных вызовов Perl так?

Настройки среды, по запросу:

ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\engmodem\Application Data
CDSROOT=Z:\Cadence\SPB_16.5
CDS_CONCEPT_NOSPLASH=TRUE
CDS_LIC_ONLY=1
CDS_SITE=Z:\Cadence\Sites\16.5
CHDL_LIB_INST_DIR=%CDSROOT%
CLIENTNAME=USENTUTTLJL3C
ClusterLog=C:\WINDOWS\Cluster\cluster.log
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=CORPUSAPP5
ComSpec=C:\WINDOWS\system32\cmd.exe
CONCEPT_INST_DIR=%CDSROOT%
FP_NO_HOST_CHECK=NO
HOMEDRIVE=H:
HOMEPATH=\
HOMESHARE=\\PF1\HOME
ICMHOME=Z:\Software\PTC\INTERC~1
INSTDIR=%CDSROOT%
LOGONSERVER=\\ENGMAHO5
LSF_BINDIR=Z:\Software\LSF\bin
LSF_ENVDIR=\\hwc151\LSF_6.2\etc
MESSAGE=BROADCAST
NUMBER_OF_PROCESSORS=2
OA_PLUGIN_PATH=%CDSROOT%\Share\oaPlugIns
OS=Windows_NT
Path=C:\Program Files\Legato\nsr\bin;Z:\oracle\ora92\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Windows Resource Kits\Tools\;Z:\Software\Perl\5.8.8\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\Program Files\Support Tools\;Z:\Software\LSF\bin;C:\Program Files\PHP\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\EMC RepliStor;C:\GitStack\python;C:\GitStack\python\Scripts;C:\GitStack\git\cmd;Z:\Scripts;Z:\bin;Z:\Cadence\SPB_16.5\tools\bin;Z:\Cadence\SPB_16.5\tools\fet\bin;Z:\Cadence\SPB_16.5\tools\pcb\bin;Z:\Cadence\SPB_16.5\OpenAccess\bin\win32\opt
PATHEXT=.COM;.EXE;.BAT;.PL;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.VBS
PCB_LIBRARY=16
PERL5SHELL=cmd
PHPRC=C:\Program Files\PHP\
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 29 Stepping 1, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=1d01
ProgramFiles=C:\Program Files
PROMPT=$P$G
PULLUP_DIFF_PAIRS=TRUE
SESSIONNAME=RDP-Tcp#1
SystemDrive=C:
SystemRoot=C:\WINDOWS
TZ=EST5EDT
VISUALSVN_SERVER=C:\Program Files\VisualSVN Server\
WF_RESOURCES=Z:\oracle\ora92\WF\RES\WFus.RES
windir=C:\WINDOWS
4b9b3361

Ответ 1

Оказалось, что причина этого странного поведения была неверно определена. Переменная PERL5SHELL: cmd.exe (интерпретатор оболочки в Windows) следует вызывать с некоторыми параметрами для правильной обработки - после некоторых обновлений параметры пропали. )

Кстати, в Doc он сказал, что Perl обычно предполагает, что строка cmd.exe/x/c в качестве исполняемого файла оболочки так или иначе, если переменная окружения PERL5SHELL не определена вообще.

P.S. Мне очень нравится эта тема: она четко показывает цель комментариев. )