Добрый день!

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



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

Скока мона повторять одно и то же? Наверно, надо закрепить подобную тему.


1. Запускаем make --v  и убеждаемся, что он безнадежно стар.

2. Заходим и обновляем http://sourceforge.net/project/showfiles.p...lease_id=587379

Я до этого скачивал последнюю версию WinAvr, где есть вся подборка утилит - не работает мой makefile
Сейчас скачал mingw32-make по приведенной ссылке - тоже не работает мой makefile. Ошибка такая же!

Это не мейк дурит, а sh. Я так не нашёл нормального. Выкинул нафиг.
А имена возьмите в кавычки, и всё заработает.

Кстати, это как раз заработало только под make 3.81


Раньше - тоже глюки были.

Там в комплекте подборка утилит чуть ли не 2003 года сборки. Со всеми глюками. Я писал Эрику Веддингтону об этом, но он не хочет обновлять утилиты, мотивируя тем, что у msys нет нормального инсталлятора, а скачивать кучу архивов и собирать из них набор утилит ему лень (там во многих архивах одни и те же файлы и разобраться, какой из них более свежий - довольно муторно). Об одном из глюков я писал здесь.
По вашему вопросу - мне тоже кажется, что вам надо взять строку в кавычки.

Спасибо всем. Заработало: обновил make и взял строки в кавычки

Это действительно шелл (о чем написано в сообщении об ошибке, которое надо было внимательно читать), а не мейк. Но шелл в данном случае вовсе не дурит, а ведет себя совершенно правильно. Ему передали такую команду:
В этой команде первый ничем не экранированный пробел стоит после c:/Files/IAR. Поэтому c:/Files/IAR шелл трактует как имя команды, все остальное - как ее параметры.
Также замечу, что эту вызвавшую ошибку команду мейк выводит на экран, и ее тоже стоило внимательно прочитать - все стало бы ясно.

Согласен, в данном случае шелл ведёт себя правильно. Я просто выразил своё негативное к нему(шеллу) отношение (Под виндой конечно, думаю что в родной среде он хорош.)

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

Да. Да. Да! Поэтому я согласился, что в этом случае шелл ведёт себя правильно

А вот пример неправильного поведения (их у меня много):

кусок makefile:



как это работает без шелла (удалил из пути):


и с шеллом (вернул):



Видите разницу? Под шеллом Rar не увидел папочки /src/term! Я живу себе в полной уверенности, что у меня всё занычено в архив, а не тут-то было. Вот такая вот засада
Поэтому я выкинул sh, и ничуть не жалею.

ЗЫ. Только не говорите, что это Rar виноват, потому что у меня много других примеров

Несложно заметить, что пропущены все папки с символом '\'
Для знакомых мне шеллов (кроме виндового cmd) символ '\' имеет спецательное значение, отсюда и все (Ваши) проблемы.
А rar (под DOS/Win) и cmd просто не понимают разницы между '\' и '/' в путях

Я это заметил. Но объясните мне тогда, зачем sh, вместо того, чтобы просто вызвать заказанную программу с заказанными аргументами, ещё и подменяет системные вызовы для этой программы? Я так понял, что не срабатывает рекурсивный поиск внутри самого Rar-а.

Я пытался обойти это, заставив sh вызвать родной виндовый cmd:





Где тут слеши? И где он нашёл буквы "gp"?

Попробуйте также заставить sh вызвать какую-нибудь встроенную команду виндового командного интерпретатора (cmd), типа md:





И так далее, и тому подобное...

Мне кажется, что они сначала пропущены были, а только потом оказалось, что они с '\'
Расшифровываю: в выдаче на экран в строках эти '\' - уже от самого rar, он при рекурсивном разборе каталогов так их напечатал.
А в случае с шеллом - в самом
обратніх слешей в передаваемой строке нет.

Теперь в чём разница, и как бороться, насколько я помню:

В случае с sh (и, кажется, с некоторыми вариантами самого make, тогда и упрятывание sh из путей не помогает) раскрутка '*'-чек происходит до вызова rar и ему передаются уже все обнаруженные файлы. Но эта раскрутка происходит без спуска вниз по каталогам.

Проверка - слепить свою програмку, которая распечатывает argv[], вместо rar.exe подставить её и посмотреть, что реально передаётся (у меня одно время такая программка prargs.exe болталась в c:\bin)

Правка - замаскировать '*'-ки, чтобы они не имели специального смысла

Если я правильно понимаю, то rar, строя путь для вложенных папок, использует дефолтный в ОС разделитель для папок '\', не догадываясь, что его запускают в *nix-образном шелле.
Возможно, проще будет формировать скриптом список файлов, подлежащих упаковке, и скармливать его rar'у.

Почему sh должен что-то знать про встроенные команды cmd? Для sh аналогичная команда называется mkdir, и он ее с радостью исполнит. Но cmd, будучи запущенным в sh, на mkdir гнусно выругается.

У меня тоже есть такая - 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 звал шелл.

Зачем? Вроде всё уже выяснили. Там исходники и подкаталог с исходниками (*.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 дурит? И не только в моём понимании этого слова?



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

Не обязательно.
а) Тот make мог и одиночные команды на sh отправлять - он имеет право одиночные команды выполнять прямым вызовом системы, но не обязан.
б) А если он все команды со звёздочками обязан отправить shell-у, то тогда он вообще ни при чём. А если sh.exe нет, то виндовая версия в качестве shell вроде как %COMSPEC% зовёт - так ли, сяк ли, а звёздочки он сам не разворачивает.

Это дело относится к довольно старым временам перехода от борландического make на GNU-тый, на какой машине что стояло и как работало - уже не вспомню. Возможно, проблемы с "на одном компе звёздочки маскировать надо, на другом нет" связаны были именно с тем, что на одном был sh.exe, а на другом не было.
Так что тут "мопед не мой".

То есть, я неправильно понял фразу "(и, кажется, с некоторыми вариантами самого make, тогда и упрятывание sh из путей не помогает)"? Или это Вы уже сейчас переосмысливаете, по итогам обсуждения? Просто у меня тоже воспоминания времён появления первых gnuтых мейков под винду, и тоже в процессе перехода с borland make. И вроде бы, мейк сам разворачивал. Потому что шелл я стабильно выкидывал:-)
Да и логично это, в принципе-то. Раз шелл разворачивает звёздочки, то и мейк, действуя в обход шелла (неважно почему, потому что он так решил, или потому что не нашёл sh), то есть, по сути выполняя функции шелла, по идее должен поступать так же.
Надо покопаться в закромах, может и отыщу такой мейк:-)

Это я и в первом, и во втором случае пытаюсь объяснить свои воспоминания, которых на момент первой фразы было меньше, чем появилось впоследствии :-)

Понятно:-) Поискал среди старых мейков, не нашёл. Может и правда не было такого:-)
Зато в процессе поисков нашёл подтверждение кривости sh
Цитата из readme.W32 от мейка:

Собственно, как раз в моём случае sh и не смог "handle quoted strings correctly".
Скачал мейк, собрал его с опцией BATCH_MODE_ONLY_SHELL. Завтра проверю