Leif W wrote, quoting me:
>> (except for one nit -- the `[/\]' regex *isn't*
>> portable; you need to write `[\\/]', with the backslash *first* in
> Ahh yes, that was my first guess, but I figured bash-centric, that the
> single quotes prevent the escape, so I had \/, which I thought looked
> too much like a V, so I swapped. :-)
It isn't just the order of the slash and the backslash which matters
here; there are some, arguably broken, regex parsers about, which will
not see a backslash in a char group, unless it is placed first in the
group, so for maximum portability, you need the `[\\/]' syntax.
The other issue is the number of backslashes required to make grep see
one in the first place. As you correctly state, the single quotes
inhibit one level of escaping; this is certainly true of bash, and I
am not aware of any portability issues to other shells, in this respect.
So, if you pass `[/\]' to grep, wrapped in single quotes at the *shell*
level, grep will indeed see `[/\]'. However, another round of escape
interpretation occurs within grep itself, so that char group reduces
to the pair of characters `/]'; this is missing its closing `]', so
the regex is malformed, and grep should complain.
If you turn it around, to become `[\/]' in the shell, then grep just
sees a char group comprising a solitary `/'; you need `[\\/]' to
have grep see a char group comprising both types of slash.
If you didn't use single quotes around the regex, in the shell, then
you would need `[\\\\/]', to have grep see just one `\' within the