Ну и опять смелое предположение:
после запроса есть ошибка в логике обработки пустого массива, например, бесконечно рекурсивный while, который останавливается интерпретатором внутри exec и не фиксируется в логах по причине какой-то допустимости.
Ну и не рассказано ничего про @/try-catch запуски – из поведения костылей можно почерпнуть немного сведений.
И костыль уровня "кресло-каталка":
в первом скрипте делать exec( 'mysql -u*** -p*** `select ...`' ) и парсить этот вывод, и посмотреть опять пустой результат.
Ну если echo отладка говорит, что всё хорошо, значит можно применить костыль с проверкой на пустой var_dump и имитацией пустого объекта на выходе. Может даже придется прописать переходы через try/catch.
Если проверять на ==8 и отнимать 2, то так и будет.
В другом варианте была проверка на ==7 без изменения счетчика, там в цикле переход на 6 по условию на уменьшение проходит самостоятельно. Запись в порт нормально стоит, перед изменением счетчика.
scp работает поверх ssh, все передаваемые данные шифруются. Перехват возможен при подмене ключа шифрования. Гуглить "Man in the middle".
Для подключения через разные прокси достаточно позаботиться о достоверности ключей – лучше всего расскажут про это мануалы для ssh и scp.
лучше на полагаться на везение, а все-таки выделить отдельное пространство для битрикса. В конце концов, на битрикс средства нашлись, на впс-ку точно найдутся.
Предполагаю, что тень расчитывается в отдельный слой, который расположен "рядом" со слоем элемента. Но когда идет перерасчет по масштабу, для тени координаты считаются не от элемента, а от слоя при 100% размере. И так получаются погрешности, которые еще страшнее после округления.
