Здравствуйте!

На новом хостинге столкнулся с проблемой не объявляются суперглобал массив $_SERVER, самое интересное что делается только когда я запускаю скрипт через крон, проверил в php.ini стоит register_globals = on. Запускаю через браузер все нормально, а через крон нет. Подскажите как решить эту проблему если это возможно.

Спасибо!   

Я когда пускал через 

php <скрипт> - вроде тоже там ничего не было

Попробуй что-то типа:

 /usr/bin/wget -q -O /dev/null http://nastandart.com/clear.php

а, откуда взяться массиву $_SERVER при запуске скрипта в cli-режиме ?
из мануала

web сервер  у вас не запущен следовательно и переменной быть не может.
2brother79 решение кривое на мой взгляд.

и зачем так обязательно нужен $_SERVER? может стоит пересмотреть архитектуру и отказаться от его использования

интересная формулировка. я ранее пребывал в мнении, что все адреса (вэб и физические) строятся исключительно от $_SERVER

а зачем web-адреса скрипту работающему из консоли?
а физические есть два пути
1. задать константув начале  и от нее строить все пути
2. chdir(dirname(__FILE__)); в начале скрипта и строить все пути как относительные от скрипта

запустить модуль, к примеру



как я узнаю с чего должна начинаться константа? у меня движок может быть расположен где-угодно. сейчас он определяет своё местоположение через $_SERVER

__FILE__ работает везде?
и как всё же из него узнать корень сайта? ведь это только местоположение самого файла

еще есть $_ENV

не сталкивался чтобы не работало
ну вы же знаете где файл у вас относительно корня лежит

у меня $_ENV - array(0) { }

Добавлено через 31 секунду


не знаю

может, на новом хостинге есть $HTTP_SERVER_VARS?   

Ой, ну ребят вы меня насмешили. 



Если логически поразмыслить, как вообще можно полагаться на данные, которые не гарантированы?
Я всю жизнь считал, что строить пути нужно на основании информации о файле, который был исполнен интерпретатором, либо записью в конфигурационном файле. И уж если по идеологии Zend'а, полагаться исключительно на include_path. Но никак не на DOCUMENT_ROOT, к примеру, из массива $_SERVER (сколько я видел несчастных, которые напоролись на эти грабли).

спасибо всем, придется ручками определять константу ROOT_DIR   

ни разу не напарывался, а везде где возникал вопрос о построении абсолютных путей всегда рекомендовали искать хвосты в $_SERVER

и то что она присутствует не везде, тоже первый раз слышу

на что же тогда опереться? где взять корень сайта?
а также, (мы же говорим теперь уже про общий случай, не только про консольный вариант?) откуда можно выдрать query_string и всю строку запроса? 

Строка запроса есть только в случае вебсервера.

В консоли это argc, argv

Добавлено через 1 минуту и 18 секунд
Для поиска пути

http://ua.php.net/manual/en/language.const....predefined.php

__DIR__
__FILE__

не совсем понимаю, как это мне даст выяснить корень



а как же универсальность? неужели нельзя сделать, чтобы скрипт одинаково работал в обоих вариантах? или придётся писать отдельную версию для работы под cron, к примеру?

Используя относительные пути (или правило их построения для модулей системы)

Варианта собственно два.
Или система говорит модулю, где и кто лежит.
Или существуют правила формирования путей для модулей.
Есть третий вариант - хардкодинг
В противном случае никто не знает ничего   И система не работоспособна 


Вообще-то да, лучше отдельный вариант.

А универсальность реализуется легко. Собственно функционал выносишь в отдельный модуль. А к нему пишешь два интерфейса - консольный и веб.

В зависимости от места применения используешь тот или иной интерфейс.

т.е. два разных варианта. фигово



мдя. собсна ручками при установке прописываем системе (одному главному скрипту) где она находится, а от неё строим все пути

bars80080, возникло ощущение после твоих постов, что php-скрипт - некий червь, шныряющий по просторам интернета, и не знающий, ничего

вот и у меня возникло такое ощущение, когда вдруг сказали, что переменные сервера вдруг могут оказаться недоступными

есть хоть что-то стабильное в этом мире?

bars80080, собственно, про QUERY_STRING я ничего не говорил. От этой части не зависит работоспособность кода.
На вопрос - как быть, можно дать несколько советов.

1. Используйте конфиг для определения корня и при подключении его относительные пути. 
Этот вариант хорош, если вы не таскаете файлы постоянно из папки в папку, в которых подключается конфиг.

/www/s.ru/config.php


/www/s.ru/htdocs/index.php


2. Пропишите в php.ini или стартовом/конфигурационном файле include_path как /www/sitename.ru.
В таком случае, мы считаем, что любой инклуд из любого места будет происходить с учетом этого пути.

Или тоже самое при помощи ini_set.

С Апачем и потерей DOCUMENT_ROOT можно столкнуться при особых обстоятельствах.

Для конфигурирования кроновских скриптов идеологически верно, на мой взгляд, использовать отдельный конфиг.
Вернее не так, у вас для проекта должна быть конфиграция разделена на общий конфиг (подключение к бд и т.п.) и конфигурации приложения (WEB, CLI режими, к примеру).

Добавлено через 3 минуты и 35 секунд

Есть прямые руки и еще раз прямые руки. Ну и хостинги с кривыми руками есть, а еще есть новые технологии, нестандартные задачи, PHP в FASTCGI режиме под Nginx'ом и забытые заголовки. Всякое бывает.

Хм, а тебя не смущает что работа с файлами и БД организовывается несколько по-разному?

К тому же даже в случае cron есть вариант вызывать именно web вариант (выше уже говорили) 

cron wget "url-скрипта"

Это сообщение отредактировал(а) Simpliest - 18.9.2009, 16:20

Я бы за такое убил/уволил.

Зато это пишется на целых 4ре минуты быстрее, чем CLI интерфейс к модулю 

Simpliest, CLI-интерфейс к модулю пишется единожды, централизованный раннер. А wget особенно прекрасен когда я намертво запрещу исполнение PHP скрипта веб-сервером более 30 секунд. Про частные случае, кривые руки и глупых админов мы не говорим.

ну, вообще-то это разные вещи. общаться с файлами напрямую или с неким интерфейсом

а предложение: запустить скрипт - само по себе не несёт какой-то принадлежности, потому и вызывает отторжение, что для одной работы приходится иметь два разных стартера



на это я могу ответить только новостью, что мы не пишем на машинных кодах, хотя были бы прямые руки...
могу напомнить, что есть такая хрень, как perl, глядя на которую кто-то в своё время придумал php. вроде тоже самое, но удобство.
да и сам пхп - суть надстройка над C
теперь придётся писать надстройку над пхп, чтобы в разных ситуациях скрипт работал одинаково

А Standalone и Web приложение это тоже разные вещи.

Я не открою вам Америку, но большинство программистов десктоп-приложений не знают даже об MVC, просто потому что представление и логика у них в одном месте (это в вебе они заметно разделены)

понятие запустить скрипт и запустить скрипт автоматически - не очень разные

Брр, кто-то из нас двух бредит.

Формат запуск CLI-скрипта из командной строки и по cron абсолютно одинаков

имя_скрипта.php параметр1 параметр2

Вы же хотите вызывать Веб-приложение из командной строки - что есть нонсенс (извращенные методы есть и уже обсуждались).
Эдак вы докатитесь до требований сделать единый номер телефона для милиции и девочек по вызову.

послушайте, вы сейчас начинаете вгрызаться в какой-то инструментарий не видя сути дела.

есть программа которая выполняется при запросе клиента, возникает резонный вопрос - запустить её автоматически, без участия человека. разработчик пишет приложение, которое делает это. всё отлично, всё понятно. одно только "но". он почему-то пишет механизм в котором часть системы не работает. 
это по определению кривой концепт, просто потому, что он не реализует поставленной цели - заменить человека. а вы говорите, что так и должно быть. причём здесь какие-то кли-шмли?

Это сообщение отредактировал(а) brother79 - 19.9.2009, 07:07

Я не понимаю вашего негодования 
Какая часть системы и где у вас не работает?
Вам не кажется что вы что-то путаете?

Вот посмотрите, у меня в Win7 имеется прорва драйверов для тьмы устройств. Но видеокарта у меня одна конкретная.
Все классно, все показывается, но зачем-то разработчики написали механизм, в котором часть системы (прорва драйверов) не работает.


Я как раз суть вижу. А вот вы похоже не разбираетесь.

У нас есть задача - расчет амортизации. Мы берем и пишем приложение, которое будет именно этим заниматься.
Мы получили параметры, отдали результат. Поэтому у нас все работает.
Взаимодействие с пользователем нам абсолютно до лампочки - это не наша задача.

А вот если у нас встанет задача предоставить возможность расчета через веб, да, еще и, взаимодействуя с пользователем. То мы берем и пишем пользовательский интерфейс, который будет обращаться к задаче "расчет амортизации".
Потом, внезапно, у вас возникла задача сделать приложение запускающееся автоматически. Собственно мы берем и реализуем его, а оно уже обращается к задаче "расчет амортизации".

IZ@TOP, не зря говорил, что CLI интерфейс может быть написан единожды, для массы задач. Единственое что важно, это чтобы они все имели сходное построение точек входа (API).
Точно так же Web интерфейс может быть написан единожды, для массы задач. (и те же требования унифицированного API).

Добавлено через 3 минуты и 40 секунд
Резюмируя:

CLI-приложение
Web-приложение

Это разные вещи, выполняющиеся в разных средах, но могущие решать сходные задачи. У вас же каша, вы считаете это все одним приложением. 
TheBat и web-Gmail это почтовые клиенты, более того они могут работать с одним и тем же ящиком, но это разные задачи, и разные системы.

Скажем проще: все, что исполняется в режиме консоли, будь-то crontab задачи или вручную исполняемые скрипты - по сути сервисные приложения, для которых не так важен язык, на котором они написаны. Это может быть perl, python, shell (bash,sh,csh). Единственная связь в нашем случае, это API (набор классов, если хотите) под Web-интерфейс и для сервисных задач написанный на одном языке. И это естественно, что у нас для Web и обслуживающего задачи в кроне интерфейса будут разные раннеры - FrontController и CliController, например.
Про конфигурацию я уже объяснял. Тут важно понимание сущности приложений и того, что нельзя совместить конфигурацию консольного и Web-приложения, но можно объединить системные настройки.