Я сделал ярлык Windows со следующей целью:
D:\APPS\cygwin64\bin\mintty.exe /bin/env PATH=/local/bin:/usr/local/bin:$PATH /bin/bash --login -i
Я ожидал, что это добавит путь с заданными значениями, но это не так:
$ echo $PATH
/usr/local/bin:/usr/bin:/local/bin:/usr/local/bin:$PATH:/usr/lib/lapack
т.е. текст $PATH вошел в содержимое без расширения.
Как побороть?
Ну, я вижу, что это немного поздно, но, надеюсь, это может помочь вам или кому-то еще, имеющему подобную проблему.
Поскольку вы используете ярлык Windows, вместо использования синтаксиса для расширения переменной среды cygwin/* nix ($VAR_NAME) вам, вероятно, просто нужно использовать синтаксис для расширения Windows/CMD.exe (%VAR_NAME%). Кроме того, я связываю две Викиучебники ниже, которые должны охватывать почти все, что вам когда-либо нужно делать с пакетными файлами для дальнейшего использования.
Тем не менее, я ожидал бы, что ваш синтаксис также сработает, и я полагаю, что есть какой-то способ, чтобы расширения происходили, так сказать, на "другой стороне". Если я смогу найти способ работы со скриптом запуска терминала, я обновлю этот ответ.
Рекомендации:
Примечания / Предостережение Emptor
Сценарии командной оболочки cmd оставляют желать лучшего, и я думаю, что вы можете легко найти в Google что-то, что поможет вам разобраться во всех деталях. Я просто хотел упомянуть об этом и упомянуть, что ничто не мешает вам использовать что-то вроде «MinGW-x64» (я рекомендую исследовать разницу между «MinGW-x64» и оригиналом, если вы сомневаетесь; они поддерживаются отдельными лица), или что-то вроде Cygwin, с которым у вас уже есть некоторый опыт, любой из которых позволит вам выполнять скрипты sh/bash .
MinGW-x64 упрощен и имеет неполную реализацию POSIX из-за некоторых концепций, которые несовместимы с подсистемой Windows без какой-либо дополнительной поддержки (ну, я думаю, во время выполнения Microsoft VC; и я думаю, что есть обстоятельства, когда вам нужно по крайней мере с MinGW, если не MinGW-x64), но я упомяну об этом в первую очередь, поскольку это «нативное» (то есть «быстрое») решение.
Cygwin предоставляет свой «уровень совместимости» .dll который обеспечивает довольно полную среду POSIX, за счет (а) некоторых довольно значительных накладных расходов (по крайней мере, в некоторых случаях) и (б) наличия довольно сложной дополнительной .dll , которая должна быть предоставляется с любым программным обеспечением, которое вы делаете вместе с ним, и по цене / выгоде (в зависимости от вашей точки зрения), будучи достаточно хорошо привязанным к GPL, если вы используете его для своего проекта и ссылаетесь на уровень совместимости.
Однако в качестве альтернативы в этом ответе упоминается предложение лицензии Red Hat Cygwin для условий лицензии не-GPL для Cygwin, если вы того пожелаете. (И, конечно, при условии, что это экономически выгодно для вас и вашего проекта.) Тем не менее, для личных или внутренних сценариев оболочки (т. Е. Не «распределенных», то есть, не охватываемых GPL), это вполне может быть хорошим выбором, и почти наверняка будет лучше, чем возиться с особенностями продукт эпохи DOS все еще застрял, поддерживая плохие решения, принятые более 30 лет назад.