Почему чтение -p не будет работать, если вы используете curl для получения сценария bash? [Дубликат]
У меня возникла проблема с этим, когда я использовал AngularJS для доступа к моему API. Тот же запрос работал в SoapUI 5.0 и ColdFusion. У моего метода GET уже был заголовок Access-Control-Allow-Origin.
Я узнал, что AngularJS делает запрос пробных запросов. ColdFusion по умолчанию генерирует метод OPTIONS, но в нем не так много, эти заголовки специально. Ошибка возникла в ответ на этот вызов OPTIONS, а не на мой намеренный вызов GET. После того, как я добавил метод OPTIONS ниже в свой API, проблема была решена.
<cffunction name="optionsMethod" access="remote" output="false" returntype="any" httpmethod="OPTIONS" description="Method to respond to AngularJS trial call">
<cfheader name="Access-Control-Allow-Headers" value="Content-Type,x-requested-with,Authorization,Access-Control-Allow-Origin">
<cfheader name="Access-Control-Allow-Methods" value="GET,OPTIONS">
<cfheader name="Access-Control-Allow-Origin" value="*">
<cfheader name="Access-Control-Max-Age" value="360">
</cffunction>
2 ответа
Решение tty работает. Протестируйте его с помощью этого кода, например:
$ date | { read -p "Echo date? " r </dev/tty ; [ "$r" = "y" ] && cat || echo OK ; }
Echo date? y
Sat Apr 12 10:51:16 PDT 2014
$ date | { read -p "Echo date? " r </dev/tty ; [ "$r" = "y" ] && cat || echo OK ; }
Echo date? n
OK
На терминале появится приглашение от read, а read ждет ответа, прежде чем принять решение об эхо-дате или нет.
То, что я написал выше, отличается от приведенной ниже строки двумя основными аспектами:
read -t 1 __response </dev/tty
Во-первых, опция -t 1 дает read тайм-аут в одну секунду. Во-вторых, эта команда не предоставляет подсказки. Комбинация этих двух, вероятно, означает, что, хотя read был вкратце , запрашивая ввод, вы этого не знали.
-
1– nfarrar 14 April 2014 в 22:14
Основная причина, по которой это не работает, - это, как указано OP,
-
|& lt; pipe & gt; который используется, отправляет стандартный вывод из первой команды в качестве стандартного ввода во вторую команду. В этом случае первая команда -
, которая передает загруженный скрипт через канал своему интерпретаторуwget -q -O - http://myscript.shbash - . Оператор
readв скрипте использует тот же стандартный вход для получения его значения.
Таким образом, он разрушается, потому что read не ожидает ввода от вас, а берет его из собственного скрипта. Пример:
$ cat - <<EOF | bash
> set -x
> read p
> somecommand
> echo \$p
> EOF
+ read p
+ echo somecommand
somecommand
В этом примере я использовал здесь-документ, который передается по каналу в bash. Сценарий позволяет отлаживать с помощью set -x, чтобы показать, что происходит. Как вы видите, somecommand никогда не выполняется, а фактически считывается read и сохраняется в переменной p, которая затем выводится с помощью echo (обратите внимание, что $ был экранирован, чтобы избежать замены в здесь -document).
Итак, как мы можем заставить это работать тогда?
Первым из них никогда не подключаться к интерпретатору, например {ba,k,z,c,tc,}sh. Это некрасиво и его следует избегать, даже если он чувствует себя естественным делом. Лучше всего использовать любой из его опций:
bash -c string: Если присутствует опция-c, тогда команды считываются из строки. Если после строки есть аргументы, они назначаются позиционным параметрам, начиная с$0.$ bash -c "$(command you want to pipe)"Это также работает для
zsh,csh,tcsh,ksh,shи, вероятно, много других.
-
1– carry0987 26 August 2018 в 10:03