在字符串 README_* 和 REAME_IMP_* 之间应用正则表达式
Apply a Regex between string README_* and REAME_IMP_*
我使用 grc
为 ls
命令的结果着色。
目前,我有以下规则在蓝色背景上以白色前景显示文本。我为此做了 :
#README
regexp=(README_[^.]*$)
colours=on_blue blink
现在我希望以 README_IMP_*
开头的字符串(星号 *
代表任何其他字符串)显示在红色背景上的白色前景中。
我在同一个文件中做了:
#README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
但问题是即使我输入 $ touch README_IMP_any_string
,文本也会不幸地显示在蓝色背景的白色前景中,也就是说,第一条规则 regexp=(README_[^.]*$)
优先于 regexp=(README_IMP[^.]*$)
.
如何使用适当的正则表达式(使用 grc
)区分字符串 README_any_string
和 README_IMP_any_string
?
上的正则表达式 grc
引擎示例
更新 1: 按照 @Ludovic Kuty
的建议,如果我像这样颠倒 2 条规则之间的顺序:
#README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
# README
regexp=(README_[^.]*$)
colours=on_blue blink
第二条规则似乎覆盖了第一条,下图说明了这一点:
如您所见,文件 READ_IMP_1
是蓝底白字,而不是预期的红底白字。
更新 2: 据我所见,文件 conf.ls
是从上到下读取的,我无法解释为什么负数 regexp=(README_(?!IMP)[^.]*$)
在我创建 README_string
时不匹配,其中字符串是除 IMP
.
之外的任何字符串
比如我的conf.ls
,我暂时设置为:
# README with no IMP after
regexp=(README_(?!IMP)[^.]*$)
colours=on_blue blink
# README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
如果创建一个名为 README_for_example 的文件,那么后者将是 'on_red blink' 颜色,而另一个 README_*
带有 *
而不是包含 IMP
的字符串] ,将为白色:
为什么 regexp=(README_(?!IMP)[^.]*$)
在这种情况下不匹配?
也许 dircolors
和 grc
之间存在冲突?
这里是 ~/.dircolors 的开头:
#NORMAL 01;37 # global default, although everything should be something.
FILE 01;37 # normal file
DIR 32 # directory
LINK 01;36 # symbolic link
FIFO 40;33 # pipe
SOCK 01;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
如您所见,我评论了 NORMAL
行,认为它可以进行更改,但实际上,没有任何后果。
看起来 lest regexp 规则具有优先级并且即使匹配错误也会应用...
更新 3:
鉴于没有人能够提出解决方案这一事实,我认为我将不得不修改 ls.c 并按照之前的 post 重新编译。我明白了,用核弹杀鸡就好了,但我好像也没有别的办法了。
更新 4: 这是 @NechesStich
建议的最后一次尝试:
# README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
# README with no IMP after
regexp=README_[^.I][^.]*$|README_[^.][^.M][^.]*$|README_[^.][^.][^.P][^.]*$|README_I$|README_IM$
colours=on_blue blink
不幸的是,README_*
(其中 * 不以 IMP 开头)和 README_IMP_*
(* 任何字符串)之间的区别。
我得到以下结果:
如您所见,README_* 很好识别,其中 README_IMP_1
是白色的:
我认为普通文件和 grc 文件之间的白色冲突来自 ~/.dircolors :
#NORMAL 01;37 # global default, although everything should be something.
FILE 01;37 # normal file
DIR 32 # directory
LINK 01;36 # symbolic link
FIFO 40;33 # pipe
SOCK 01;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
不明白为什么dircolors
优先于grc
。
它值得更多的调查,我会做其他的测试。
更新 5 这里是 grc
的文档 doc grc 中关于字符串着色策略的摘录:
**count** is one of words: once, more, stop, previous, block or unblock
- **once** means that if the regexp is matched, its first occurrence is coloured and the program will continue with other regexp's.
- **more** means that if there are multiple matches of the regexp in one line, all of them will be coloured.
- **stop** means that the regexp will be coloured and program will move to the next line (i.e. ignoring other regexp's)
- **previous** means the count will be the same as for the previous line
- **block** marks a start of a multiline block of text, coloured with the same colour
- **unblock**, obviously, marks the end of such a block
example:
# this is probably a pathname
regexp=/[\w/\.]+
colour=green
count=more
this will match `/usr/bin`, `/usr/local/bin/`, `/etc/init.d/syslogd` and similar strings and paint it with green.
Another example:
regexp=^-{1,2}\s{0,1}$
colours=red
count=block
-
regexp=^\s{0,5}$
colours=default
count=unblock
this will turn all correctly formatted mail signatures red.
Regular expressions are evaluated from top to bottom, this allows nested and overlapped expressions. (e.g. you colour everything inside parentheses with one colour, and if a following expression matches the text inside parentheses, it will be also coloured).
你能看到我的申请吗?
来自阅读 https://github.com/garabik/grc/blob/master/grcat 上的源代码(第 157-165 行)
您可以看到 grc 不考虑以 # 或 \n 开头的行来开始新规则,只考虑以其他非字母字符开头的行,并且如果您查看其他示例,它们会使用 ===== 分隔规则==
这就是为什么只应用了最后一条规则,因为它们没有正确分开,它们相互覆盖
像这样分开应该可以
# README with no IMP after
regexp=README_(?!IMP)[^.]*$
colours=on_blue blink
=======
# README_IMP
regexp=README_IMP[^.]*$
colours=on_red blink
我使用 grc
为 ls
命令的结果着色。
目前,我有以下规则在蓝色背景上以白色前景显示文本。我为此做了 :
#README
regexp=(README_[^.]*$)
colours=on_blue blink
现在我希望以 README_IMP_*
开头的字符串(星号 *
代表任何其他字符串)显示在红色背景上的白色前景中。
我在同一个文件中做了:
#README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
但问题是即使我输入 $ touch README_IMP_any_string
,文本也会不幸地显示在蓝色背景的白色前景中,也就是说,第一条规则 regexp=(README_[^.]*$)
优先于 regexp=(README_IMP[^.]*$)
.
如何使用适当的正则表达式(使用 grc
)区分字符串 README_any_string
和 README_IMP_any_string
?
grc
引擎示例
更新 1: 按照 @Ludovic Kuty
的建议,如果我像这样颠倒 2 条规则之间的顺序:
#README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
# README
regexp=(README_[^.]*$)
colours=on_blue blink
第二条规则似乎覆盖了第一条,下图说明了这一点:
如您所见,文件 READ_IMP_1
是蓝底白字,而不是预期的红底白字。
更新 2: 据我所见,文件 conf.ls
是从上到下读取的,我无法解释为什么负数 regexp=(README_(?!IMP)[^.]*$)
在我创建 README_string
时不匹配,其中字符串是除 IMP
.
比如我的conf.ls
,我暂时设置为:
# README with no IMP after
regexp=(README_(?!IMP)[^.]*$)
colours=on_blue blink
# README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
如果创建一个名为 README_for_example 的文件,那么后者将是 'on_red blink' 颜色,而另一个 README_*
带有 *
而不是包含 IMP
的字符串] ,将为白色:
为什么 regexp=(README_(?!IMP)[^.]*$)
在这种情况下不匹配?
也许 dircolors
和 grc
之间存在冲突?
这里是 ~/.dircolors 的开头:
#NORMAL 01;37 # global default, although everything should be something.
FILE 01;37 # normal file
DIR 32 # directory
LINK 01;36 # symbolic link
FIFO 40;33 # pipe
SOCK 01;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
如您所见,我评论了 NORMAL
行,认为它可以进行更改,但实际上,没有任何后果。
看起来 lest regexp 规则具有优先级并且即使匹配错误也会应用...
更新 3:
鉴于没有人能够提出解决方案这一事实,我认为我将不得不修改 ls.c 并按照之前的 post 重新编译。我明白了,用核弹杀鸡就好了,但我好像也没有别的办法了。
更新 4: 这是 @NechesStich
建议的最后一次尝试:
# README_IMP
regexp=(README_IMP[^.]*$)
colours=on_red blink
# README with no IMP after
regexp=README_[^.I][^.]*$|README_[^.][^.M][^.]*$|README_[^.][^.][^.P][^.]*$|README_I$|README_IM$
colours=on_blue blink
不幸的是,README_*
(其中 * 不以 IMP 开头)和 README_IMP_*
(* 任何字符串)之间的区别。
我得到以下结果:
如您所见,README_* 很好识别,其中 README_IMP_1
是白色的:
我认为普通文件和 grc 文件之间的白色冲突来自 ~/.dircolors :
#NORMAL 01;37 # global default, although everything should be something.
FILE 01;37 # normal file
DIR 32 # directory
LINK 01;36 # symbolic link
FIFO 40;33 # pipe
SOCK 01;35 # socket
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
不明白为什么dircolors
优先于grc
。
它值得更多的调查,我会做其他的测试。
更新 5 这里是 grc
的文档 doc grc 中关于字符串着色策略的摘录:
**count** is one of words: once, more, stop, previous, block or unblock
- **once** means that if the regexp is matched, its first occurrence is coloured and the program will continue with other regexp's.
- **more** means that if there are multiple matches of the regexp in one line, all of them will be coloured.
- **stop** means that the regexp will be coloured and program will move to the next line (i.e. ignoring other regexp's)
- **previous** means the count will be the same as for the previous line
- **block** marks a start of a multiline block of text, coloured with the same colour
- **unblock**, obviously, marks the end of such a block
example:
# this is probably a pathname
regexp=/[\w/\.]+
colour=green
count=more
this will match `/usr/bin`, `/usr/local/bin/`, `/etc/init.d/syslogd` and similar strings and paint it with green.
Another example:
regexp=^-{1,2}\s{0,1}$
colours=red
count=block
-
regexp=^\s{0,5}$
colours=default
count=unblock
this will turn all correctly formatted mail signatures red.
Regular expressions are evaluated from top to bottom, this allows nested and overlapped expressions. (e.g. you colour everything inside parentheses with one colour, and if a following expression matches the text inside parentheses, it will be also coloured).
你能看到我的申请吗?
来自阅读 https://github.com/garabik/grc/blob/master/grcat 上的源代码(第 157-165 行)
您可以看到 grc 不考虑以 # 或 \n 开头的行来开始新规则,只考虑以其他非字母字符开头的行,并且如果您查看其他示例,它们会使用 ===== 分隔规则==
这就是为什么只应用了最后一条规则,因为它们没有正确分开,它们相互覆盖
像这样分开应该可以
# README with no IMP after
regexp=README_(?!IMP)[^.]*$
colours=on_blue blink
=======
# README_IMP
regexp=README_IMP[^.]*$
colours=on_red blink