Помогите прописать путь в скрипте
узнай у админа полный путь, где хоумдир твоего апача лежит - он может быть любым абсолютно
/var/www/html/...
лучше-таки почитать конфиг httpd
лучше-таки почитать конфиг httpd
у меня есть пароль доступа по фтп. Это не поможет? 
нет, не поможет. Но вряд ли админ откажет тебе в такой вещи, как полный путь к хоумдиру. Если, конечно, админ адекватный и настроено всё нормально
>у меня есть пароль доступа по фтп.
ну и как запускать скрипт собираешься?
ну и как запускать скрипт собираешься?
ну скрипт-то не обязательно на шелле
о наличие админа к сожалению неизвестно как это странно ни звучит 
в httpd.conf записан такой путь:
/usr/local/apache/htdocs
но он не работает.
интересно, нормально, что прописан apache/htdocs, а отображается в эксплорере www/htdocs
в httpd.conf записан такой путь:
/usr/local/apache/htdocs
но он не работает.
интересно, нормально, что прописан apache/htdocs, а отображается в эксплорере www/htdocs
нормально, если соответствующий симлинк стоит.
Но ты уверена, что это именно твой httpd.conf? На этой машине один апач и один хост?
Но ты уверена, что это именно твой httpd.conf? На этой машине один апач и один хост?
мне так помнится, что сайт лежит на хосте "squirrel". и значит все настройки были сделаны централизовано. думаю, это мой httpd.conf. В любом случае я его взяла из соседней папки.
из соседней к чему? к корневой папке фтп? А как ты туда попала?
а что, на похапе чтоли?
причём тут шелл. раз ssh не дали, то и crontab не дали.
есть правда любители запускать кроновые задания с помощью wget
я даже видел
x x x x x wget http://localhost/cron.php
а если не крон, то зачем абсолютный путь
и вообще, автор, привязываться к абсолютному пути - дикое зло
причём тут шелл. раз ssh не дали, то и crontab не дали.
есть правда любители запускать кроновые задания с помощью wget
я даже видел
x x x x x wget http://localhost/cron.php
а если не крон, то зачем абсолютный путь
и вообще, автор, привязываться к абсолютному пути - дикое зло
я по фтп могу попасть:
а от туда в папку "www", в которой лежат cgi-bin, htdocs, conf.
а от туда в папку "www", в которой лежат cgi-bin, htdocs, conf.
с удовольствием укажу не абсолютный.
скажите как?
скажите как?
шелл-таки доступен
~your-user/www/htdocs вероятно
ну как сказать... в контексте поиска по сайту - действительно, запускать индексатор через пхп - "красиво".
Но у меня куча скриптов юзает абсолютные пути, ибо даже в пределах одной машины скрипты на разных хостах обмениваются данными, пишут друг другу файло и т.д.
Но у меня куча скриптов юзает абсолютные пути, ибо даже в пределах одной машины скрипты на разных хостах обмениваются данными, пишут друг другу файло и т.д.
шелл-таки доступенне факт, конечно...
>Но у меня куча скриптов юзает абсолютные пути
удачи при переезде
если только это не внутри vps, который легко мигрировать
удачи при переезде
если только это не внутри vps, который легко мигрировать
>не факт
.bash_history
или был, но отобрали.
.bash_history
или был, но отобрали.
удачи при переездеспасибо, у меня на работе всё рядышком
или был, но отобралину потому и написал, что не факт. У самого на моем личном хостинге такая же история. Был шелл, а теперь нету - и чувак не помнит, когда убрал. Ну, да мне он особо у меня и не нужен - лишь бы почта работала
эм, а что мешает абсолютный путь писать в конфиг ровно в одном месте и при переезде менять?
то, что пути эти в скриптах прописаны, а не в конфиге
ну дак, надо сразу думать. а то разбросать констант по коду, а потом самому мучаться.
ты прошлую страницу почитай - у меня скрипты оперируют файлами на другом хосте, делают файлы для другого хоста и т.д.
К тому же многое из этого писалось еще до того, как я пришел (а я там уже 2.5 года). На днях меняли РНР4 на РНР5 - тьфу-тьфу, практически безболезнено
К тому же многое из этого писалось еще до того, как я пришел (а я там уже 2.5 года). На днях меняли РНР4 на РНР5 - тьфу-тьфу, практически безболезнено
и что мешает хранить абсолютный путь до твоих дир (на каком бы хосте они ни находились) в одном файле конфига рядом со скриптами? я просто разницы не вижу.
апд: это вообще был ответ 'у по поводу переезда =)
апд: это вообще был ответ 'у по поводу переезда =)
то, что абсолютных путей этих довольно много, к сожалению...
почему-то так никто не делает.
если уж догадались вынести путь к www-корню в отдельный конфиг, то лучше использовать ~/ вместо этого
если уж догадались вынести путь к www-корню в отдельный конфиг, то лучше использовать ~/ вместо этого
Ура! Скрипт запустился!
Помогло просто переписать скрипт в чистый файл и назвать другим именем (просто назвать другим именем не помогало). Уже встречала такой глюк на другом сервере
Большое спасибо и Федечке за помощь!
Помогло просто переписать скрипт в чистый файл и назвать другим именем (просто назвать другим именем не помогало). Уже встречала такой глюк на другом сервере
Большое спасибо и Федечке за помощь!
в конце первой строки стояло \r\n ?
Насколько я понял, там стоял относительный путь?
Есть такая пакость, что если /a/xxx.php - симлинк на /b/xxx.php, то, если в xxx.php мы говорим, например, include 'yyy.php' - подключается всегда /b/yyy.php.
Есть такая пакость, что если /a/xxx.php - симлинк на /b/xxx.php, то, если в xxx.php мы говорим, например, include 'yyy.php' - подключается всегда /b/yyy.php.
Первая строка была естественно
Если там что-то стояло, то невидимое
#! /usr/bin/perl.
Если там что-то стояло, то невидимое
#! /usr/bin/perlЧто, прямо так, с пробелом?
просто если исходники правились и тестировались под виндой, то, с некоторой вероятностью (это зависит от настроек редактора и от настроек ftp-клиента в исходнике все строки заканчивались на \r\n, в том числе, и первая строка с указанием пути до интерпретатора.
на сервере же эта строка воспринималась как строка, заканчивающаяся на \n, соответственно, символ \r (он же ^M) становился продолжением слова perl.
само собой, бинарника perl^M в системе нет, поэтому это приводит к ошибке.
когда был создан новый файл, возможно, в редакторе были другие настройки (UNIX-like EOL поэтому это помогло, а переименование не помогало.
это, всего лишь, версия )
на сервере же эта строка воспринималась как строка, заканчивающаяся на \n, соответственно, символ \r (он же ^M) становился продолжением слова perl.
само собой, бинарника perl^M в системе нет, поэтому это приводит к ошибке.
когда был создан новый файл, возможно, в редакторе были другие настройки (UNIX-like EOL поэтому это помогло, а переименование не помогало.
это, всего лишь, версия )
остальным скриптам не мешает
Если я не путаю, то была такая ситуация на другом сервере. Я помещала страницу html с фоновыми картинками. Все картинки копировались на сервер нормально, а одна картинка становилась с синем оттенком. Я копировала ее несколько раз, удаляла - ничего не помогало. пока я ее не переименовала и не скопировала под новым именем.
И на этом же сервере был такой же глюк со скриптом.
Наверное, этому должно быть какое-то логичное объяснение...
И на этом же сервере был такой же глюк со скриптом.
Наверное, этому должно быть какое-то логичное объяснение...
ну дык я был прав
дело было не в путях а вообще в запуске
дело было не в путях а вообще в запуске
Оставить комментарий
zakysj50
Использую готовый скрипт для поиска по сайту.На локальном компе он прекрасно работает при введение следующих путей:
Как эти пути прописать для сервера, работающего под линуксом?
Конкретно, интересует начало для $base_dir (=?/www/htdocs). Мне кажется, что оно должно быть стандартным. Наверное, там нужно указать home или что-то в этом роде.