Re: переменные $1
День добрый.
23.04.2020 0:35, Slawa Olhovchenkov пишет:
On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:
Ну да, одно из возможных решений - отучить регулярные выражения в
map'е трогать $1..$N. С другой стороны - конфигурации вида
map $uri $foo {
~(.+) $1;
}
тоже никто не отменял.
не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.
Тут есть два нюанса:
1. Механизм формирования $1..$N - общий, и если map не трогает
$1..$N - то конструкция выше работать не будет. А делать так,
чтобы $1..$N использовали результат выполнения конкретного
регулярного выражения, а не просто последнего - логично как раз в
рамках rewrite'а, где это конкретное регулярное выражение
очевидно. (Ну то есть в рамках map'а следом тоже встанет вопрос,
когда в правой части будет $bar$1, где $bar - ещё один map с
регулярным выражением. Но это, очевидно, надо будет решать так
же.)
2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
быть должны, те же именованные captures - вполне логично
использовать и много кто использует на практике. Использовать
побочные эффекты в виде $1..$N - с моей точки зрения странно, но
теоретически и это вполне может быть.
я понимаю откуда взялось.
что не отменяет гемороя.
https://trac.nginx.org/nginx/ticket/564
Patches are welcome.
6 лет...
Да, за 6 лет никто не сподобился даже попытаться прислать патч.
Что как бы позволяет предложить, что - не жмёт.
или никто не может разобраться.
Это не "или", это именно что "не жмёт". Затраты на попытаться
разобраться - превышают количество проблем, которые создаёт
текущее поведение.
ну хоть бы в документацию большими буквами.
я не получил большого гемороя только из-за того что в процессе у меня
и так полный дебаг был включен по другому поводу и я сразу увидел
такой фифект.
А что, кроме лени, мешает не пользоваться $1$2$3 вообще, а использовать
1. поименованные переменные (?...)
$uniqvar
2. везде, где переменные не нужны или не использовать скобки, а если не
возможно или не удобно, использовать отказ от создания переменной (?:...) ?
и тогда точно будем знать что
map $... {
~^start(?)end$ '1';
}
location /(?.+)/$ {
rewrite ^(?:.+)$ /$mapvar/$locvar/? break;
приведет к тому, что хочется.
нет ?
/А
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:
> > > Ну да, одно из возможных решений - отучить регулярные выражения в
> > > map'е трогать $1..$N. С другой стороны - конфигурации вида
> > >
> > > map $uri $foo {
> > > ~(.+) $1;
> > > }
> > >
> > > тоже никто не отменял.
> >
> > не понимаю возражения.
> > я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> > других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> > $foo сформировался и никому ничего больше от этого map не требуется.
>
> Тут есть два нюанса:
>
> 1. Механизм формирования $1..$N - общий, и если map не трогает
> $1..$N - то конструкция выше работать не будет. А делать так,
> чтобы $1..$N использовали результат выполнения конкретного
> регулярного выражения, а не просто последнего - логично как раз в
> рамках rewrite'а, где это конкретное регулярное выражение
> очевидно. (Ну то есть в рамках map'а следом тоже встанет вопрос,
> когда в правой части будет $bar$1, где $bar - ещё один map с
> регулярным выражением. Но это, очевидно, надо будет решать так
> же.)
>
> 2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
> быть должны, те же именованные captures - вполне логично
> использовать и много кто использует на практике. Использовать
> побочные эффекты в виде $1..$N - с моей точки зрения странно, но
> теоретически и это вполне может быть.
я понимаю откуда взялось.
что не отменяет гемороя.
> > > > > https://trac.nginx.org/nginx/ticket/564
> > > > >
> > > > > Patches are welcome.
> > > >
> > > > 6 лет...
> > >
> > > Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> > > Что как бы позволяет предложить, что - не жмёт.
> >
> > или никто не может разобраться.
>
> Это не "или", это именно что "не жмёт". Затраты на попытаться
> разобраться - превышают количество проблем, которые создаёт
> текущее поведение.
ну хоть бы в документацию большими буквами.
я не получил большого гемороя только из-за того что в процессе у меня
и так полный дебаг был включен по другому поводу и я сразу увидел
такой фифект.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 07:14:05PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > А это нормально что переменные $1..$N не являются локальными для
> > > > > регэкспа?
> > > > >
> > > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > > браться из map.
> > > > > Что-то мне кажется это не логично.
> > > >
> > > > Это следствие того, что regexp и использование $1..$N могут быть
> > > > разнесены, например, в конструкциях вида (цитата из
> > > > http://nginx.org/r/if):
> > > >
> > > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > > set $id $1;
> > > > }
> > > >
> > > > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > > > даже есть тикет:
> > >
> > > не для rewrite, а для map.
> > > вроде как логично ожидать, что map срабатывает выдавая указанную
> > > переменную без каких-либо дополнительных побочных эффектов.
> >
> > Ну да, одно из возможных решений - отучить регулярные выражения в
> > map'е трогать $1..$N. С другой стороны - конфигурации вида
> >
> > map $uri $foo {
> > ~(.+) $1;
> > }
> >
> > тоже никто не отменял.
>
> не понимаю возражения.
> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> $foo сформировался и никому ничего больше от этого map не требуется.
Тут есть два нюанса:
1. Механизм формирования $1..$N - общий, и если map не трогает
$1..$N - то конструкция выше работать не будет. А делать так,
чтобы $1..$N использовали результат выполнения конкретного
регулярного выражения, а не просто последнего - логично как раз в
рамках rewrite'а, где это конкретное регулярное выражение
очевидно. (Ну то есть в рамках map'а следом тоже встанет вопрос,
когда в правой части будет $bar$1, где $bar - ещё один map с
регулярным выражением. Но это, очевидно, надо будет решать так
же.)
2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
быть должны, те же именованные captures - вполне логично
использовать и много кто использует на практике. Использовать
побочные эффекты в виде $1..$N - с моей точки зрения странно, но
теоретически и это вполне может быть.
> > > > https://trac.nginx.org/nginx/ticket/564
> > > >
> > > > Patches are welcome.
> > >
> > > 6 лет...
> >
> > Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> > Что как бы позволяет предложить, что - не жмёт.
>
> или никто не может разобраться.
Это не "или", это именно что "не жмёт". Затраты на попытаться
разобраться - превышают количество проблем, которые создаёт
текущее поведение.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
ср, 22 апр. 2020 г. в 21:14, Slawa Olhovchenkov :
> On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > А это нормально что переменные $1..$N не являются локальными для
> > > > > регэкспа?
> > > > >
> > > > > Т.е. если например у нас есть rewrite и там что-то захватывается,
> а в
> > > > > результате используется еще и результат map с регэкспом, то $1
> будет
> > > > > браться из map.
> > > > > Что-то мне кажется это не логично.
> > > >
> > > > Это следствие того, что regexp и использование $1..$N могут быть
> > > > разнесены, например, в конструкциях вида (цитата из
> > > > http://nginx.org/r/if):
> > > >
> > > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > > set $id $1;
> > > > }
> > > >
> > > > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > > > даже есть тикет:
> > >
> > > не для rewrite, а для map.
> > > вроде как логично ожидать, что map срабатывает выдавая указанную
> > > переменную без каких-либо дополнительных побочных эффектов.
> >
> > Ну да, одно из возможных решений - отучить регулярные выражения в
> > map'е трогать $1..$N. С другой стороны - конфигурации вида
> >
> > map $uri $foo {
> > ~(.+) $1;
> > }
> >
> > тоже никто не отменял.
>
> не понимаю возражения.
> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> $foo сформировался и никому ничего больше от этого map не требуется.
>
> > > > https://trac.nginx.org/nginx/ticket/564
> > > >
> > > > Patches are welcome.
> > >
> > > 6 лет...
> >
> > Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> > Что как бы позволяет предложить, что - не жмёт.
>
> или никто не может разобраться.
>
если бы у кого-то реально подгорало, уже бы замотивировал всех причастных.
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
>
> > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> >
> > > Hello!
> > >
> > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > >
> > > > А это нормально что переменные $1..$N не являются локальными для
> > > > регэкспа?
> > > >
> > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > браться из map.
> > > > Что-то мне кажется это не логично.
> > >
> > > Это следствие того, что regexp и использование $1..$N могут быть
> > > разнесены, например, в конструкциях вида (цитата из
> > > http://nginx.org/r/if):
> > >
> > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > set $id $1;
> > > }
> > >
> > > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > > даже есть тикет:
> >
> > не для rewrite, а для map.
> > вроде как логично ожидать, что map срабатывает выдавая указанную
> > переменную без каких-либо дополнительных побочных эффектов.
>
> Ну да, одно из возможных решений - отучить регулярные выражения в
> map'е трогать $1..$N. С другой стороны - конфигурации вида
>
> map $uri $foo {
> ~(.+) $1;
> }
>
> тоже никто не отменял.
не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.
> > > https://trac.nginx.org/nginx/ticket/564
> > >
> > > Patches are welcome.
> >
> > 6 лет...
>
> Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> Что как бы позволяет предложить, что - не жмёт.
или никто не может разобраться.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> >
> > > А это нормально что переменные $1..$N не являются локальными для
> > > регэкспа?
> > >
> > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > результате используется еще и результат map с регэкспом, то $1 будет
> > > браться из map.
> > > Что-то мне кажется это не логично.
> >
> > Это следствие того, что regexp и использование $1..$N могут быть
> > разнесены, например, в конструкциях вида (цитата из
> > http://nginx.org/r/if):
> >
> > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > set $id $1;
> > }
> >
> > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > даже есть тикет:
>
> не для rewrite, а для map.
> вроде как логично ожидать, что map срабатывает выдавая указанную
> переменную без каких-либо дополнительных побочных эффектов.
Ну да, одно из возможных решений - отучить регулярные выражения в
map'е трогать $1..$N. С другой стороны - конфигурации вида
map $uri $foo {
~(.+) $1;
}
тоже никто не отменял.
> > https://trac.nginx.org/nginx/ticket/564
> >
> > Patches are welcome.
>
> 6 лет...
Да, за 6 лет никто не сподобился даже попытаться прислать патч.
Что как бы позволяет предложить, что - не жмёт.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
>
> > А это нормально что переменные $1..$N не являются локальными для
> > регэкспа?
> >
> > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > результате используется еще и результат map с регэкспом, то $1 будет
> > браться из map.
> > Что-то мне кажется это не логично.
>
> Это следствие того, что regexp и использование $1..$N могут быть
> разнесены, например, в конструкциях вида (цитата из
> http://nginx.org/r/if):
>
> if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> set $id $1;
> }
>
> Для rewrite'а это, конечно, не нормально, надо править. Про это
> даже есть тикет:
не для rewrite, а для map.
вроде как логично ожидать, что map срабатывает выдавая указанную
переменную без каких-либо дополнительных побочных эффектов.
> https://trac.nginx.org/nginx/ticket/564
>
> Patches are welcome.
6 лет...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> А это нормально что переменные $1..$N не являются локальными для
> регэкспа?
>
> Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> результате используется еще и результат map с регэкспом, то $1 будет
> браться из map.
> Что-то мне кажется это не логично.
Это следствие того, что regexp и использование $1..$N могут быть
разнесены, например, в конструкциях вида (цитата из
http://nginx.org/r/if):
if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
set $id $1;
}
Для rewrite'а это, конечно, не нормально, надо править. Про это
даже есть тикет:
https://trac.nginx.org/nginx/ticket/564
Patches are welcome.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
переменные $1
А это нормально что переменные $1..$N не являются локальными для регэкспа? Т.е. если например у нас есть rewrite и там что-то захватывается, а в результате используется еще и результат map с регэкспом, то $1 будет браться из map. Что-то мне кажется это не логично. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
