I have a list of the data in this format:
eth0: flags=73<UP,LOOPBACK,RUNNING> mtu 1500
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0xfe<compat,link,site,host>
loop (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=73<UP,LOOPBACK,RUNNING> mtu 1500
inet6 ::1 prefixlen 128 scopeid 0xfe<compat,link,site,host>
loop (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I need to select eth1 (which is the first word and it is a word which always starts with e) it is not followed by 127.0.0.1 (which could also appear later in the following line).
here eth0 is not qualified because it is followed by 127.0.0.1
I tried everything and nothing seems to work. is it even possible with a regular expression? if yes then how?
Not sure about the Ubuntu implementation details but you can make use of a negative lookahead:
^eth\d+(?=:)(?!.*\n.*[^0-9]127\.0\.0\.1[^0-9])
^eth\d+(?=:) - the start of the line must be "eth", followed by one or more digits, and followed by a colon but do not capture the colon(?!.*\n.*[^0-9]127\.0\.0\.1[^0-9]) - make sure that the contents which follow the previous match do not contain "127.0.0.1"
@rahulKushwaha NEVER use
(.|\n)*, it is ALWAYS a wrong idea..(usually) can match linebreaks provided the right option is passed with the regex pattern.I expect that will work great on the regex101 web site since you seem to have tested it there but it won't work in any standard UNIX tool. I'm surprised the OP accepted it as the best answer.
@EdMorton The regex flavor and available toolset was unknown at the time of my answer which I addressed in my opening sentence. Users are encouraged to accept answers which helped them the most. OP is more than welcome to change the accepted answer if my answer did not help them achieve their goal.
Right, there's nothing at all wrong with your answer. As I said, I'm sure it'll work great on regex101, I'm just surprised the OP accepted it (and so effectively discouraged others from posting answers) given it won't work in any standard UNIX tool (lookaheads and
\dare the problems) and from the comment they still seem to be struggling to get it to work using whatever tool they are using.Thanks. I think it's more likely, though, that their tool doesn't support lookaheads and is interpreting the lookahead syntax as something else (e.g. maybe
(is being interpreted as the start of a capture group and?as zero-or-one repetitions, etc.) that just happens to not fail and produces the expected output for the one sample use case. But without knowing what tool the OP is using, we're all just guessing...