надо разобраться.

Мне пока недосуг, потом если не зарешаешь — гляну чо как.

@zartsoft смотри какая муть.

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

с вещами нахуй на выход

в виндовом нормально работает #!/usr/bin/python3[.x]

python3.exe не нужен

с вещами нахуй на выход

$ ./test.py bash: ./test.py: /usr/bin/python3: bad interpreter: No such file or directory

не надо тут всех за дебилов всё-таки считать, ок?

$ ?

засунь свой цигвин себе в анус

Внимание! Чтобы получить ответ вопрос надо строить так: у меня питон версии Й, есть Х, версии М, мне нужно от него П, я проделал Е, я гуглил и читал про С, но не получается Б. Чат для начинающих или чувствительных: https://telegram.me/python_beginners Питоновый грубый чат без обиняков: https://telegram.me/rudepython Книжки уже есть в канале, ищите по хештегу #manual

кстати, а с энвом ок будет под вендой?

это cmd.exe с изменённым prompt

а "bash:" в ошибке тебе тоже cmd.exe написал?

ггг

если ты гоняешь под говноэмуляторами нативный софт - пройди нахуй

а "bash:" в ошибке тебе тоже cmd.exe написал?

ага, из cmd.exe с изменённым prompt запущен баш тоже с ним

ну

твой ссаный баш и читает шибенг

ок, ок. минуту

к нему претензии

D:\Repos>test.py - запускает ёбаный редактор

это, видимо, лучше.

#!/usr/bin/python3 print(123)

это test.py

D:\>edit test.py D:\>type test.py #!/usr/bin/python3 import sys print(sys.version) D:\>test.py 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)]

D:\Repos>test.py - запускает ёбаный редактор

ты поставил ссаную анаконду или что там?

ты поставил ссаную анаконду или что там?

нет, нахер оно надо. предлагаешь сбросить нахер ассоциации?

покажи мне вывод команд: assoc .py ftype python.file

D:\>assoc .py .py=Python.File D:\>ftype python.file python.file="C:\Windows\py.exe" "%L" %*

ага, питон лончер нужен.

дык он в комплекте ж идёт с 3.3 где-то

спасибо. вывод: D:\Repos>ftype python.file File type 'python.file' not found or no open command associated with it. D:\Repos>assoc .py File association not found for extension .py

элол

как ты это ставил аще?

криворучками, видать.

кстати, а с энвом ок будет под вендой?

ну с башем и авком проблем у нас не было. с питоном - вот, кривые руки юзера (т.е. меня)

если скрещивать с башем, то надо учитывать кучу нюансов

потому что у цигвина и мсиса разное поведение, разная эмуляция

мы всех заставляем ставить мсис.

звери

хватает того что полный комплект и так с виндовым гитом прилагается

хватает того что полный комплект и так с виндовым гитом прилагается

ну вот с ним и ставят.

т.е. настраиваете патх на тамошний мсис

ну да.

и зачем вы ломаете людям систему?

и зачем вы ломаете людям систему?

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

это какойто пиздец

наверно, да.

я ебал например с билдами студии работать из под баша

вы сишный софт не собираете в процессе?

я ебал например с билдами студии работать из под баша

нет, по счастью. новый тулинг от ms для net core работает под башем. и под powershell, и под cmd.

можно заставить макоёбов поставить повершелл. но тогда мне надо будет переступить через своё отвращение к нему.

павершелл для работы как шелл неудобен примерно полностью

гонять тамошние кмдлеты - это ок гонять бинарники с диска - параша

блядь, а мсис проёбывается с нормальным шибенгом и лончером. Вот тварь.

в ряде случаев надо корректно квотить всё подряд и запускать через & "some\fucking.exe" ...

в ряде случаев надо корректно квотить всё подряд и запускать через & "some\fucking.exe" ...

да-да, там что-то жесть постоянная. но я всегда думал, что я просто не умею.

шибенг в питоне через ихний лянчер

в нормальном варианте когда запускается питоноскрипт через кмд/эксплорер/чонитьвиндовое, происходит цепочка: ShellExecute (экпслорер) читает реестр, в поисках ассоциации для .py, находит питон.файл, получает оттуда py.exe CreateProcess(py.exe, script.py, args) py.exe смотрит на аргументы и ключи раз всяких -2/3 нет, значит смотрим первые байты скрипта читаем оттуда, и определяем если там /usr/bin/env - значит ищем по PATH если там /usr/bin/python - значит ищем строго по реестру выдираем версию из шибенга, консультируемся с py.ini (через это можно например заставить работать впридачу и pypy/iron/jy) и возможно маппим на другую строку если же там #!"any exe" то строка останется как есть с ней новый запуск CreateProcess(exe, script, args)

вся эта цепочка позволяет шибенгам работать примерно как в никсах, но при этом в цепочке процессов у нас еще и py.exe висеть будет

при этом весь механизм работает чисто за счет обычного механизма винды и py.exe в случае же со всякими мсисами и цигвинами - те пытаются эмулировать позикс. в честном позиксе шибенг обрабатывается ядром, программы тупо гоняют exec/spawn/system ('script.py')

цигвины/башы же для эмуляции читают скрипты напрямую и пытаются повторить то же самое но при этом чтобы /usr/bin работал надо либо маппить никсовые пути на виндовые, либо полагаться на PATH

и тут начинается гора нюансов

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

xkcd про стандарты. Спасибо большое.

Я твою простыню сейчас спизжу в gist, ок?

ERROR: S client not available

https://www.in-ulm.de/~mascheck/various/shebang/ это вообще каноничный ресурс

о том, почему часть никсов хавает весь шибенг, часть лишь первый аргумент, а древние не ели даже и аргументов

Splitting arguments A very few systems deliver only the first argument, some systems split up the arguments like a shell to fill up argv[], most systems deliver all arguments as a single string. See the table below. I noticed that for Linux (delivering all arguments as one string), a patch to split up was suggested on the Linux kernel mailing list (dead link, try this page, archive.org), followed by a discussion of some portability issues.

тут вообще стоит понимать как аргументы в разных ос вообще передаются в позикс апи аргументы передаются в виде массивов строк в вин апи аргументы передаются одной длинной строкой философия обработки совсем разная - в позиксе шелл обязан обрабатывать вайлдкарды, поэтому там например есть всякие shopt которые управляют глоббингом (скажем выдать ошибку если глоб не раскрывается или раскрыть в пустую строку) запущенный процесс в позиксе получит на входе уже раскрытый в список реальных файлов/аргументов глоб т.е. ls * превращается в exec(ls, file1, file2, file3)

это я знаю

в вин апи main() как и всегда получает массив, но при этом процесс получает на входе тупо строку (GetCommandLine), и црт0 код парсит его согласно своих правил

наебался несколько раз на больших глобах, пришлось xargs выучить.

dir * превращается в CreateProcess(cmd, /c, dir, *)

на винде уткнулся один раз в 64k ограничение, когда из msbuild генерил вызов своей тулы

в студии есть отдельный объектный файлик который можно прилинковать, который будет парсить иначе..

https://msdn.microsoft.com/en-us/library/8bch7bkk.aspx тут упоминание про setargv.obj про альтернативный парсинг

научился тогда "response files" - единственное, я не понял, это стандарт какой или нет. когда все аргументы в файл сливаются по принципу 1 аргумент - одна строка. Я так понял, что это каждый сам для себя придумывает

это один из вариантво эмуляции поведения позикса

response files, @-файлы - это соглашение

порт гцц под дос активно юзал этот синтакс на уровне либц чтобы обходить лимит на размеры

в досе лимит на командную строку был вообще в 128 байт, если чо

в линупсах нынче порядка 512кб насколько помню

у винды вроде 32к юникод символа

я изза всех этих нюансов и не люблю помесей нативных виндовых бинарников и позиксоэмуляторов

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

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

внезапно правило что "похуй \ или / в путях" перестает работать, например или аргументы прилетают оверквоченными

если хочется кроссплатформа и не хочется держать разные копии, то вариант ровно один переходить на питон для билда 8)

ну или там js мейби

но всю логику разницы платформ придётся вхуячивать в скрипты тогда

А почему дос не пересел на божественные слэши?

потому что он их унаследовал от CP/M

точнее не так

В никскиках наших вообще могло быть православное >

в CP/M прямые слеши использовались для свитчей каталогов там еще не существовало

как и в дос 1.0 они появились лишь в дос 2.0

Т.е. натурально >usr>local>bin>python