Поиск трех последовательных новичков?

Думаю, вам не хватает опции -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.

2
08.01.2019, 05:00
2 ответа

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*скрывается под некоторыми портами или системой пакетов за пределами пространства компиляции поставщика.

2
27.01.2020, 21:55

Вы можете использовать trдля преобразования потока в поток, который вы можете нормально обрабатывать:

stream | tr 'x\n' '\0x' | grep -qz xxx

Это превращает все xбайты в нулевые байты, а все байты перевода строки — в xs, которые можно извлечь как обычно. То есть он перемещается на один шаг по пути перевода строки -> x -> null, поэтому последовательность из трех переводов строки теперь будет последовательностью из трех xs, и никакие другие xбайты не появятся (они станут нулевыми, завершающими строками дляgrep).


Это работает с POSIX tr, но grep -zявляется расширением. Вам может это не нужно -поведение разделения здесь не требуется -и большинство greps будут обрабатывать двоичные данные, но POSIX grepтребуется только для работы с текстовые файлы , так что вы так или иначе будете зависеть от расширения.

Если ваши настоящие данные представляют собой текстовый файл или просто не зависят от -безопасного поведения двоичных файлов, вы, вероятно, сможете выжить только

stream | tr 'x\n' '\nx' | grep -q xxx

-, то есть просто поменять местами два байта. Это почти POSIX -совместимо, но, вероятно, будет работать на практике почти везде (проблема в том, что последняя строка не будет завершена правильно, поэтому это не текстовый файл,так что grepне обязательно принимать его).

Одна из возможных проблем в любом случае заключается в том, что файл без существующих xбайтов будет рассматриваться как одна очень длинная строка, которая может превысить ограничения, которые может обработать ваша grepреализация. Выбор другого ожидаемого от -до -общего байта -может обойти это.

Я был удивлен, что ваша первоначальная команда grep -qz $'\n\n\n'не работала, но у меня была ложная-положительная проблема для меня -она вела себя как grep -qz ''и всегда совпадала. Я не уверен, почему это так.

3
27.01.2020, 21:55

Теги

Похожие вопросы