Добрый день!

gnu make не хочет понимать пути с пробелами. Как объяснить?



Выдаёт следующее:
/usr/bin/sh: c:/Files/IAR: No such file or directory
make: *** [main.o] Error 127

У меня тоже есть такая - echo :-) Проверяю:
без sh:

С sh:


Точно, разворачивает, зараза! Маскирую звёздочки:


Замечательно, сработало. Снова удаляю sh:


Не очень красиво, но Rar это проглатывает нормально. Эта проблема, будем считать, решена

А как быть с другими, которые я перечислил? Как, например, запустить cmd с параметрами?



Потому, что это sh для винды. Порт, понимаете? Это подразумевает некую адаптацию под.

ЗЫ. Со слешами ReAl всё чётко разъяснил, спасибо ему

А ещё невесть когда под досом нюансы какие-то были и выходило, что единственной адекватной моделью кошки могла быть только кошка. В смысле натуральный .exe


Такое впечатление, что cmd интересовал меня в "эпоху" использования борландовского make, который как родной для доса/винды был.
Потом как-то интересовало наоборот - как заставить make всё делать через sh (он имеет право одиночные команды выполнять прямым обращением к ос без создания subshell)

О, кстати, а

в первых строках makefile не спасёт отца русской демократии?
Правда, тогда всё через cmd будет работать.

Да у меня тоже такая кошка есть:-) Выпытывала у IAR EW параметры командной строки компилятора/линкера, чтоб к med-у присобачить

И как, удалось? А то тут сразу видна засада с этими звёздочками. Не все же программы такие добрые как Rar, некоторым наверняка не понравится экранирование, если make вдруг решит запустить их без sh...

Дык, я этого эффекта добился удалением sh:) А иногда всё же хочется что-нибудь этакое завернуть в makefile, скриптовое:-)))

Да где-то писал. Достаточно сделать так, чтобы команда не была одиночной :-)
Например,
переписать как
и всё - у нас уже не набор одиночніх команд, а типа скрипт :-)
Т.е. к сугубо одиночной команде какой-то эхо-оживляж редко когда мешает.

Спасибо, попробую пооживлять:-)

А можно еще показать содержимое директория src (вывод ls -l src например)?
А должен был? Папочка src/term не подпадает ни под одну из указанных в командной строке масок (в "term" нет точки например)!
Не буду. Он не виноват. В этом случае, похоже, виноват программист.
Почему Вы решили, что он не срабатывает? Насколько я вижу, у Вас в директории ./src/ есть файлы config.c, main.c и rs1.c. Правильно? Во вложенных в src директориях (том же term например) есть файлы с такими именами? Что-то мне подсказывает, что нет. Тогда какой рекурсии Вы ждете? При наличии файлов с одинаковыми именами рекурсия работает, я только что проверил. Причина разного поведения rar'а кроется в передаче ему при вызове разных аргументов, а вовсе не подмена каких-либо системных вызовов...

ИМХО в данном случае проше изучить документацию на шелл и правильно им пользоваться. В частности, если программист не хочет, чтобы шелл выполнял подстановку имен файлов вместо содержащих "*" аргументов, он должен сообщить об этой шеллу, например заэкранировав звезду бэкслешем или взяв аргумент в одинарные кавычки...

Это единственный шелл, о котором я неодновретно слышал отрицательные отзывы именно в плане работы с make. Это плохой, негодный шелл. Лучше им просто не пользоваться. Параметры же ему передаются с символом слэш вместо минуса.

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

Сообщение отредактировал alx2 - Jun 5 2009, 11:17

Зачем? Вроде всё уже выяснили. Там исходники и подкаталог с исходниками (*.c и *.h)


Узнаю линупсоеда:-) Виноват может быть кто угодно, только не линупс:-) Вы бы почитали тред повнимательнее, ведь мы с ReAl-ом уже во всём разобрались.
Да, с этим уже разобрались. Sh не подменял системные вызовы, sh зачем-то самовольно развернул звёздочки. Его старание похвально, но я от него этого совсем не ждал. Получилось во вред.
Повторю, я говорю всё это применительно к винде. Наверное, для юниксов это всё естественно и само собой, но для меня, виндового пользователя, это оказалось совершенно неожиданно.

Какие нарекания? Всё, что он умеет, он прекрасно делает и из-под мейка. Я сейчас именно им и пользуюсь. cmd - это родной шелл для винды. И много чего нельзя сделать иначе чем через него. И в том, что sh не хочет запускать cmd, а вижу признаки заговора линупсоедов:-)
А слеш там обратный, чем он мешает sh?



А вот это интересно, спасибо, проверю.

Вы обознались. Я линукс не ем, и вообще им не пользуюсь. И даже слова такого тут не произносил. В том, что программист не прочитал документацию на используемую программу, и не знал, что звезда для шелла имеет специальное значение, виноват уж точно не линукс... А сообщение я отредактировал, удалив то, о чем ReAl и другие уже написали. Там изначально вдвое больше было написано... Если что-то лишнее и осталось - прошу прощения за недосмотр.
К сожалению, сейчас уже вряд ли вспомню. Одной из проблем, насколько мне помнится, было очень уж сильное ограничение на длину командной строки. Коллега сталкивался с невозможностью сделать "echo ...список файлов... >listfile".
Ой, извините, я уже ничего не понимаю. Просто каша какая-то - все в одну кучу свалено! Как это "sh не хочет запускать cmd"? Кто вообще спрашивает его желание? Что нормальному шеллу в командной строке указывают, то он и выполняет. При чем тут линуксоеды? Каким боком шеллу мешает обратный слеш? Прошу прощения, но я ничего не могу на это ответить. Я не сталкивался ни с проблемой сделать что-либо без использования cmd, ни с отказом шелла что-либо запускать, ни с помехами от бэкслешей.

Впрочем, по поводу использования внутренних команд cmd.exe - вот фрагмент Makefile'а моего коллеги:

Да не суть. Главное, что не виндузоид

Хм. Я совершенно не собирался использовать sh, он сам как-то затесался...

Это, имхо, очень устаревшие сведения.

Вот именно. А этот - самовольничает. В сообщении №13 я привёл пример моей попытки вызова cmd.

Это потому, что вы работаете не под виндой. То есть, извините, берётесь судить о том, чего не пробовали. Я уверен, что вы отлично знаете, как устроен sh, но под виндой у него есть некоторые особенности. И именно о них я и веду речь.

Вашему коллеге повезло, make решил не вызывать sh при выполнении этой команды. У меня такое без sh тоже замечательно работает.

Рад, что сейчас ситуация улучшилась. Беру свои слова о cmd.exe обратно.
AHTOXA, Вы опять неправы. Во-первых, под виндой я работал. Во-вторых, программы, о работе которых я говорил (make, rar, zsh), - кроссплатформенные, существуют под самые разные ОС. Не пользовался я только cmd.exe в качестве шелла, но я ведь сразу уточнил, что сужу о его качестве с чужих слов. Еще раз прошу прощения за то, что информация о нем оказалась устаревшей.
Извините за недоверие, но до сих пор приведенные Вами примеры неправильного поведения шелла оказывались примерами незнания его работы. Подозреваю, что большинство других примеров (Вы говорили что у Вас их много) - такие же. Ну не могу я представить, как еще среди кучи существующих шеллов можно не найти ни одного нормального. Думаю, что пробуя шеллы и столкнувшить с какими-то затруднениями, Вы, не разобравшись, поспешили в выводами об их низком качестве. Я использую Z shell (помнится, я его Вам когда-то рекомендовал), никаких особенностей и различий в его работе под виндой и не виндой я не замечал.
Не вижу в этом никакого везения. Программы работают в соответствии с документацией. Ладно, в предыдущем примере добавляю ";" в конце команды. Теперь make записывает команду во временный файл, вызывает для его выполнения Z shell, он в свою очередь вызывает cmd.exe, который выполняет копирование (все это видно если запустить make с ключом -d). То есть при вызове одного шелла из другого (хотя я не понимаю, для чего это может быть нужно) тоже все работает.

Теперь по поводу письма номер 13. Я до сих пор его игнорировал, так как там ошибку выдает cmd, которого я как раз не знаю и которым не пользуюсь. Да и Rar'а у меня не было. Чтобы не говорили, что я сужу о том, чего не пробовал, я решил посмотреть-таки и приведенный там пример. Скачал и установил rar, создал такой Makefile:
Создал директории bak, prj и src, положил туда тестовые файлы. Результат - ошибка не воспроизводится. Команда выполняется, на долю секунды появляется новое окно, в bak создается архив со всем содержимым текущего директория.

Пардон, откуда взялся zsh? Вроде до сих пор шла речь о sh? Что же касается кросплатформенности, то именно об этом я и веду речь. Что при адаптации к другой платформе надо учитывать особенности этой платформы. Почему, например, make под винду перестал разворачивать звёздочки? Я думаю, что из-за того, что такое поведение (разворот звёздочек) противоречит общепринятому под виндоуз. Почему sh не перестал? Потому что он пуп земли, и поэтому он мне не нравится

Вполне возможно. Я не готов тратить месяцы на изучение инструмента, единственное назначение которого (в моём применении) - вызвать другую программу.

Я пробовал разные версии sh. Про zsh я, извините, забыл.

А sh - не может:


Ага, теперь хоть понятно, что за "gp" Но всё равно непонятно, что не так... А, кажись понял
Меняю кавычки на одинарные, и телемаркет! Всё заработало. Большое Вам спасибо за это
Правда, архив пустой, но это от экранирования наверное. Да, точно. Убрал экранирование звёздочек - всё работает.


Интересно... Давайте уж вывод make -d, чтоб разобраться досконально. И что там с подкаталогами? Хотя в этом случае как раз работает cmd, который не умничает

Это шутка, или Вы действительно не понимаете? Что такое, по-вашему, "sh"? Это имя конкретной программы? Это просто исторически сложившееся название команды, вызывающей шелл. Такое имя было у Thompson shell в первой версии AT&T UNIX'а. Не хотите ли Вы сказать, что у Вас именно тот самый Thompson shell? С тех пор утекло много воды и появилась масса самых разных шеллов. Они часто имеют и собственные команды запуска, например "bash" для Bourne-Again shell или "zsh" для Z shell - это дает возможность иметь сразу несколько разных шеллов. Таким образом, когда говорят "bash", "tcsh", "zsh" или "ash" - обычно понятно, какой именно шелл имеется в виду. А вот просто "sh" без дополнительных уточнений не говорит ни о чем. На той машине, где я вчера заставлял gmake пускать cmd.exe из-под Z-шелла, имя исполняемого файла Z-шелла было "sh.exe"! Здесь я назвал его zsh только ради конкретизации. На моей домашней машине, за которой я сейчас пишу, команда sh - это BSD-шелл, выросший из Bourne shell. В некоторых ОС с ядром linux принято, что команда sh вызывает Bourne-Again shell (линуксисты его любят). Под телевизором у меня стоит Дримбокс - у него команда sh запускает ash. Шелл из комплекта виндового ресурскита (не знаю как он называется) тоже, насколько я помню, имел имя файла sh.exe. Поэтому я до сих пор не знаю, какую именно программу Вы использовали в качестве шелла.
Приведите, пожалуйста, пример, в котором GNU make (и именно он!) под одной платформой звездочку разворачивает, а под виндой - нет. У меня, еще раз извините, есть сомнения в существовании такого различия в поведении make.
Тогда извините, но я верну Вам почти ваши же слова. Высказывая негативное к нему (инструменту) отношение, говоря, что он дурит, подменяет системные вызовы и т.п., Вы беретесь судить о том, чего не знаете...
Наверняка Вы его неправильно используете.
Мне-то за что??? Я кроме "у меня работает" и не сказал ничего. Я так и не знаю даже, какой у Вас там шелл!!!
Сейчас машина с виндой недоступна, завтра вечером постараюсь вывод привести.

sh - это та программа, которую вызывает make, неужели непонятно?

Тем, кто под виндой пользуется Winavr, winarm, msp-gcc и проч. и проч. и проч - очень даже говорит. На всякий случай посмотрел:

Я помню, что предыдущие версии gnu make разворачивали звёздочки. 3.79-cygwin, емнимс. Частично это подтверждает ReAl в посте #14. Но Вы, конечно, можете продолжать сомневаться.
Это нечестно. Про подмену вызовов - я уже давно признал что это не так. А насчёт остального - привёл примеры. Вы считаете, это нормальное поведение программы? Не дурит? Я так не считаю.

Ну это уже совсем ни в какие ворота. Я привёл пример makefile, показал, что происходит. Зачем тогда весь этот спор, если аргументы игнорируются?

За то, что благодаря этому дурацкому спору с Вами, я научился запускать cmd из-под sh:) Хотя я наверное всё равно выкину это sh опять

Ок.

Ну тогда я все правильно написал про zsh - у меня под виндой make, запуская sh, вызывает именно Z-shell. Не знаю, почему Вас это удивило.
А при чем тут make? Прочитайте раздел 4.4 документации на GNU make.В случае, о котором говорил Real, звезды подставляются как раз в команду, а вовсе не в цели или пререквизиты. Таким образом, make в том примере и не должен разворачивать звезды, это не его работа. Извините за недоверие, но в том, что предыдущие версии make, вопреки документации, делали это сами, я продолжаю сомневаться.
Ни в одном из приведенных Вами примеров (пример с rar, пример с вызовом внутренней команды cmd) я не вижу расхождения поведения программ с их документацией. Да, поведение, совпадающее с описанным в документации, я считаю нормальным.
Да полно, не сердитесь Вы так. Ну вот сами рассудите. До этого уже неоднократно оказывалось, что когда поведение программы расходилось с Вашими ожиданиями, поведение программы совпадало с документацией, а Ваши ожидания - нет. Вы сами говорили, что не готовы изучать документацию на шелл. Каким именно шеллом Вы пользовались, мне не было известно. У меня Ваш пример работал без ошибок. Какой же вывод я по-вашему должен был сделать? Что именно тут Вы обнаружили ошибку в работе шелла? Еще раз извините, но это неубедительно. Мне кажется, прежде чем говорить, что нашел глюк в программе, надо десять раз свериться с ее документацией, проверить, не упустил ли чего сам... Вот если вы скажете: "В таком-то месте документации написано так, а в жизни программа работает эдак" - это будет аргумент, который вряд ли можно игнорировать. А пока Ваши аргументы - это Ваши ожидания, не подкрепленные документацией...

Кстати, раз Вы уже поняли, расскажите, что это было за "gp", которое cmd у Вас не мог найти. Любопытно все-таки...

Вот "хвост" вывода make -d, который Вы просили:

Потому что я говорил про мой sh

Позвольте я Вам процитирую, что сказал ReAl:

Курсив мой. Насколько я понимаю, здесь речь идёт именно о разворачивани звёздочек мейком в команде. Моя память говорит мне, что я также встречался с таким поведением мейка. Но доказать я сейчас конечно не смогу, я не храню кривые мейки.

Да бросьте вы. Вот моя команда в makefile:

Вот что происходит:

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

Да я собственно и не отрицал этого. Говоря "глючит", я имел в виду - "работает не так, как я ожидаю". Такая формулировка слова "глючит" примирит Вас с моим высказыванием? :-)

Дык, там же видно было:

gp - это кусочек от пути к sh (D:\kgp\bin\sh.exe). Каким образом он попал в командную строку, переданную cmd - не знаю. Может и мейк дурит. Давайте проверим. У меня есть программа ShowCmdLine.exe (ReAl напомнил), которая показывает командную строку. Итак:


Командная строка:


Красота Проверим, кто же дурит. Переименовываем ShowCmdLine.exe в sh.exe, смотрим, что передаёт make шеллу:

Вроде всё нормально, не? Значит, таки sh дурит? И не только в моём понимании этого слова?



У, через временный файл, ничего не видно