ortsuev33 вы путаете capturing subpatterns и подстановку значений из capturing subpatterns. Потенциальная неоднозначность интерпретации в случае мультисимвольного индекса (например $10 в вашем случае) описано в документации PHP, там же указано максимальное количество подстановок в таком формате (100).
В вашем случае необходимо писать ${10}, вместо $10 т.к. $10 синтаксически нельзя отличить от ${1}0
да, и не факт что обратные слэши нормально поддерживаются, лучше заменить на прямые слэши. Также убедитесь что билды совместимы между собой: они должны быть собраны одной версией Visual Studio должны иметь одинаковую разрядность (32- или 64-bit) и одинаковый thread-safety режим (либо оба TS либо оба NTS).
По поводу реализации - копать в сторону идеи о том что будет 3 компонента:
реальный долгоиграющий скрипт, как-то отдающий информацию о своём состоянии
серверный скрипт который может читать это состояние
клиенский скрипт в браузере который будет запрашивать состояние и, возможно, подавать управляющие команды.
Клиентский скрипт (3) загружается в браузер и начинает время от времени запрашивать статус долгоиграющего скрипта (1) у сервера. На сервере отвечает скрипт (2) который читает актуальный статус долгоиграющего скрипта (1) и информирует о нём клиента (3).
Сочувствую :) Тогда как вариант - делать отдельный shell скрипт с каким-нибудь curl'ом который будет дёргать ваш скрипт и в нём уже ставить необходимые timeout'ы. Вот здесь можно посмотреть их описание. Так вы хотя бы обеспечите управляемость окружения в условиях специфики вашего проекта.
Dmitry да, правильно. вы, конечно, можете закинуть в браузер скрипт который будет поддерживать соединение, но в целом это решение сложнее чем просто запускать скрипт из консоли. при условии что ваш скрипт использует какой-нибудь современный framework - переделать его на запуск из консоли в целом будет весьма тривиальной задачей.
При запросе скрипта из браузера на самом деле создаётся соединение "браузер-nginx" и, возможно, соединение "nginx-upstream" в зависимости от того какова у вас конфигурация. Если второго соединения (nginx-upstream) может и не быть (к примеру там подключение через unix socket, а не через tcp) то соединение с браузером есть и никто не будет гонять там дополнительные пакеты чтобы поддержать его в живом состоянии, оно просто будет закрыто через какое-то время, причём не обязательно по инициативе nginx. В итоге если вы хотите запускать что-то что работает долго, но отдаёт результат в браузер, а не просто использовать браузер для запуска удалённого скрипта - то реальная схема несколько другая. Если же вы просто хотите запускать скрипт на сервере - то лучше делать это из консоли, а не через браузер.
Со стороны nginx - вряд ли, но нужно помнить что TCP соединения не поддерживаются живыми автоматически, поэтому реальная ситуация может отличаться в зависимости от деталей вашей конфигурации
Кстати позволю не согласиться по поводу использования препроцессоров. У меня были проекты с 500-600кб CSS кода, поддерживать такой объём в maintainable состоянии без пре- или постпроцессора - довольно сложная задача. Кроме того препроцессор (к примеру Sass) существенно расширяет возможности для вёрстки, позволяет автоматизировать кучу рутины и добавить существенную гибкость. У меня буквально несколько дней назад появилась задача - добавить на сайт поддержку арабского языка. А это, если вы знаете, ещё и необходимость "перевернуть" весь сайт справа налево, сделать его зеркальную копию. При этом стили сайта занимают порядка 200кб. У меня базовое решение с использованием Sass уложилось в добавление пары функций, руками это сделать было бы существенно сложнее, а уж поддерживать в адекватном и синхронизированном состоянии - тем более.
HamSter Gulp - это task runner, он просто запускает задачи (без разницы какие) и выполняет их оркестрацию. Webpack - bundler, его принцип работы - построение дерева зависимостей модулей и пересборка их в bundles. Это в общем случае совершенно разные инструменты и они решают разные задачи, скорость работы здесь не имеет отношения к делу. Т.е. если для сборки необходимо выполнить ряд различных задач (возможно и не связанных непосредственно с кодом) то здесь лучше использовать Gulp, а если нужно как-то хитро перерабатывать исходные файлы - то webpack может быть более подходящим решением. Просто важно помнить что у них разные цели и, следовательно, сферы применения. Да и никто не мешает использовать их вместе, это отлично работает.
Нет, простым копированием файлов / базы. Я с ним никогда не работал, а сайты на других CMS обычно копированием переносятся без проблем. Попробую через резервную копию, спасибо
$10в вашем случае) описано в документации PHP, там же указано максимальное количество подстановок в таком формате (100).В вашем случае необходимо писать
${10}, вместо$10т.к.$10синтаксически нельзя отличить от${1}0