The problem is that I have to enter a regex into a config file of a
software which does not understand lookbehinds (probably a old version
of perl, since I get a "bad pattern <?...").
Oh, so that's why you had all those restrictions. Without the
knowledge of your restrictions, we couldn't really give you a complete
answer.
Anyway, I'm not using perl directly for this, I have to find a regex
to do that, without lookbehinds, that's it.
Are you sure you are using Perl for this? I've done similar things
myself (that is, putting a regular expression in a config file), but I
don't think it was Perl that was evaluating them. It could be that
Perl has nothing to do with this.
That's why I can not code a second pass to remove quotes after a
/field2=("[^"]*"|\S*)/ for instance, or something that would give me
the one backreference I need after a /field2=(?:"([^"]*)"|(\S*))/.
I can't use a perl module either, of course.
If fact, I cannot code at all, the only thing I can control is 1
regexp.
The main problem is that you are searching for different patterns,
depending on what your delimeter is. If you have 'value="some text"',
then you will be looking for the next '"' character to signal the end
of your pattern. But if you have 'value=some_text', then you will be
looking for whitespace to signal the end of your pattern. This flow
of logic (if-then-else) is something that regular expressions alone
weren't made to handle.
I don't think your problem has a working solution because regular
expressions lack the ability to carry out the above logic. So let me
propose two work-arounds:
1. You could modify the program that reads the config files to handle
the logic you need.
or
2. You can write a simple Perl script to convert your config file so
that all the fields have quotes around the values (whether they need
them or not). In other words, your script would change all instances
of:
field1=some_text
to:
field1="some_text"
Then you could just set your regular expression to be:
m/field[0-9]+="([^"]*)"/
and then all your fields would be extracted. Problem solved.
Of course, I would imagine that the second work-around will be much
easier for you to implement, unless there is some other restriction
that you haven't shared with us.
Hopefully you'll find a solution that works for you.
-- Jean-Luc