Думаю, вам не хватает опции -g
, потому что иначе удаленный порт будет слушать только localhost
, что означает, что любой другой хост, кроме удаленного localhost
, не сможет подключиться к нему.
С -g
он слушает 0.0.0.0
, что означает, что он доступен на всех интерфейсах, а не только на localhost
.
Как говорит ssh(1)
, опция g
"Позволяет удаленным хостам подключаться к локальным проброшенным портам. Если используется в мультиплексированном соединении, то эта опция должна быть указана на главном процессе."
Вы также упоминаете, что создали этот туннель в vagrant box. Значит, этот curl
, который вы показываете, также находится в блоке vagrant, верно? В противном случае, если вы запустите curl
на хост-системе, а не в блоке vagrant, это не сработает. Если вы хотите подключиться к туннелю из хост-системы (не внутри блока vagrant), вам придется подключиться к IP блока vagrant вместо 127.0.0.1
.
lex
(илиflex
)могут справиться с этим, например. следующее сохранено в файл tresn.l
с дополнительными правилами, в основном для предотвращения вывода по умолчанию на стандартный вывод (. Возможно, вам это нужно?)
%%
\n\n\n { exit(0); }
<<EOF>> { exit(1); }
\n\n { ; }
\n { ; }
. { ; }
%%
компилируется с неявными make
правилами плюс извлечениеlibfl*
$ CFLAGS=-lfl make tresn
lex -o lex.tresn.c tresn.l
cc -lfl -o tresn lex.tresn.c -ll
rm -f lex.tresn.c
$ printf "\n\n" |./tresn ; echo $?
1
$ printf "\n\n\n" |./tresn ; echo $?
0
в некоторых системах вам может понадобиться добавить -L/opt/local/lib
или что-то подобное в CFLAGS
или также LDFLAGS
, если libfl*
скрывается под некоторыми портами или системой пакетов за пределами пространства компиляции поставщика.
Вы можете использовать tr
для преобразования потока в поток, который вы можете нормально обрабатывать:
stream | tr 'x\n' '\0x' | grep -qz xxx
Это превращает все x
байты в нулевые байты, а все байты перевода строки — в x
s, которые можно извлечь как обычно. То есть он перемещается на один шаг по пути перевода строки -> x -> null, поэтому последовательность из трех переводов строки теперь будет последовательностью из трех x
s, и никакие другие x
байты не появятся (они станут нулевыми, завершающими строками дляgrep
).
Это работает с POSIX tr
, но grep -z
является расширением. Вам может это не нужно -поведение разделения здесь не требуется -и большинство grep
s будут обрабатывать двоичные данные, но POSIX grep
требуется только для работы с текстовые файлы , так что вы так или иначе будете зависеть от расширения.
Если ваши настоящие данные представляют собой текстовый файл или просто не зависят от -безопасного поведения двоичных файлов, вы, вероятно, сможете выжить только
stream | tr 'x\n' '\nx' | grep -q xxx
-, то есть просто поменять местами два байта. Это почти POSIX -совместимо, но, вероятно, будет работать на практике почти везде (проблема в том, что последняя строка не будет завершена правильно, поэтому это не текстовый файл,так что grep
не обязательно принимать его).
Одна из возможных проблем в любом случае заключается в том, что файл без существующих x
байтов будет рассматриваться как одна очень длинная строка, которая может превысить ограничения, которые может обработать ваша grep
реализация. Выбор другого ожидаемого от -до -общего байта -может обойти это.
Я был удивлен, что ваша первоначальная команда grep -qz $'\n\n\n'
не работала, но у меня была ложная-положительная проблема для меня -она вела себя как grep -qz ''
и всегда совпадала. Я не уверен, почему это так.