Почему Scala использует обратный shebang (! #) Вместо простого перевода интерпретатора на scala

Документация scala показывает, что способ создания scala script выглядит следующим образом:

#!/bin/sh
exec scala "$0" "[email protected]"
!#
/* Script here */

Я знаю, что это выполняет scala с именем файла script и переданными ему аргументами, и что команда scala, по-видимому, знает, как читать файл, который начинается таким образом, и игнорировать все до обратный shebang !#

Мой вопрос: есть ли причина, по которой я должен использовать этот (довольно подробный) формат для scala script, а не просто:

#!/bin/env scala
/* Script here */

Это, насколько я могу судить по быстрому тесту, делает то же самое, но менее многословно.

Ответ 1

Сколько лет в документации? Обычно такого рода вещи (часто называемые "exec hack" ) были рекомендованы до того, как /bin/env был распространен, и это был лучший способ получить функциональность. Обратите внимание, что /usr/bin/env чаще, чем /bin/env, и его следует использовать вместо этого.

Ответ 2

Обратите внимание, что это /usr/bin/env, а не /bin/env.

Нет преимуществ для использования промежуточной оболочки вместо /usr/bin/env, за исключением работы в некоторых редких античных версиях Unix, где env не находится в /usr/bin. Ну, технически SCO все еще существует, но работает ли Scala?

Однако преимущество варианта оболочки заключается в том, что он дает возможность настроить то, что выполняется, например, добавить элементы в PATH или CLASSPATH или добавить в интерпретатор такие параметры, как -savecompiled (as показано в manual). Возможно, поэтому документация предлагает форму оболочки.

Я не в команде разработчиков Scala, и я не знаю, какова была историческая мотивация для документации Scala.

Ответ 3

Scala не всегда поддерживал /usr/bin/env. Никакой конкретной причины для этого, просто, я думаю, человек, который написал поддержку сценариев оболочки, не был знаком с этим синтаксисом еще в середине 00-х. Документация соответствовала тому, что было поддержано, и я добавил поддержку /usr/bin/env в какой-то момент (iirc), но никогда не беспокоился об изменении документации. Казалось бы.