When you have a list of RE elements in [square brackets], the square-brackets part matches any of the charatcers between the brackets. So [(a.*b)] matches any line with a, b, . or *.

A good way to test your expressions it to turn on colourised output:
And then to type in the grep command with no input file specified and nothing piped in. Then just start typing. When you hit return, if your input line matches you'll see it repeated with the matching parts coloured in:
Note that the "nothing works here" line was not echoed back - it did not match the expression.

When you're done, press control-d (at the start of a line) to finish your test.

There's probably a better way to do this, but here's how I'd make an expression meaning "match any line where it contains an a but no b, OR a b but no a":
Looks ugly, but here's how it works:

• The expression is split in two parts with the | character, which means that the whole expression matches if one or other sub-expressions matches. For example a|b|c is the same as [abc].
• OK the first of the two sub-expressions is:
  
  Code:

  ^[^b]*a[^b]*$

• Let's break it down. The ^ at the start of the expression means "only match this expression if it is anchored to the start of a line".
• The [^b] part means "match any character which is not b" (yes, it's a little confusing that the ^ means "not" here and "start of line" outside [square brackets]).
• The * means "the previous bit 0 or more times" (the previous bit being the [^b] - any non-b character).
• The a is treated as a literal "a" character.
• The [^b]* as before.
• The $ means "end of line".
• So that whole thing ^[^b]*a[^b]*$ means "a whole line containing an a, but no b's".
• Now you should be able to see that the whole expression says "a line containing an a but no b's or a line containing a b but no a's".

Enjoy

Interesting thread. It's been a while since I took my bash class but I thought thatis only going match any line with zero or more instances of "a"... and that's it. From the way I understood, on the bash command line the "|" (pipe) means take the output from pre-pipe and feed, as a file, the output to post-pipe. So why does grep even have the opportunity to match the glob because it already has the output from ls? I never knew that but it's good to know that now. I'll be sure to put "quotes" around my regular expressions from now on. I also didn't know that there are more than one type of regular expression.

Good stuff.

I do know this, though:
grep = Global Regular Expression Parser

[QUOTE=zetabill]Interesting thread. It's been a while since I took my bash class but I thought thatis only going match any line with zero or more instances of "a"... and that's it.
Please re-read post #8. It will usually work, but not for the reason you might think, and when you have more than one file the current working directory it won't work at all.

That's a little ambiguous because some programs don't take their input from standard input, or don't write their output to standard output. For example, most of the GNU core utilities (grep included ) will take their input from standard input only if no files are specified as part of the command.

It is more precise to say that the pipe connects the standard output file handle of the command to the left of the pipe symbol to the standard input file handle of the command to the right of the pipe. Thus pipes are only useful for programs which read from stdin and/or write to stdout.

The shell tries to expand glob patterns before passing that argument list to programs. So in the example above, if a* matches any files, that list of files is passed to grep, and grep will not see the pattern. Again, I refer you to post #8, which has a detailed example of what is going on.

When the shell interprets a command with pipes in it, it doesn't execute the processes in the order they appear on the command line, and then move the output through them. The pipes are connected together before any of the processes create any output and then the data flows through the pipeline.

Another nice one. I wonder how many different "reasons" for the name grep there are?

Regarding the bash i just want to mention the Advanced Bash-Scripting Guide. It saved me a lot of headaches (next to the manpage ) -> some things i find faster in the man page some are better explained in the guide ...

Hi.
Like the Highlander: There Can Be Only One. ... cheers, makyo
AlsoBWK's credentials include:
( edit 1: correct quote )

im using ubuntu in vmware.
when using grep '^[a-z]$' dict-file
the output is ABCDEFGHJIKLMOOPQRSTUVWXYabcdefghijklmnopqrstuvwxyz
thts capital A-Y then lowercase a-z

is it wmware fault?

Given:
Regular expression
[[:alpha:]][0-9]*[[:alpha:]]

Using the above expression, I grep on the file
/usr/share/dict/linux.words
on the bash prompt.
i.e.

Then, the following output was observed-

10-point
10th
11-point
12-point


etc..

How come this output is seen?
Isn't the output supposed to be similar to

ab
a1b

i.e. an alphabet followed by digit followed by an alphabet
OR
an alphabet followed by an alphabet.

please don't drag up dead threads. new question = new thread.

Grep searches for substring. You'll note that all strings found contain two consecutive alphabet characters (not unexpected when searching a dictionary).

Use ^ to match the beginning of a line, and $ to match the end of the line. Note that $ also has special meaning to the shell, so you might want to add some quotes.

Groetjes,

Kees-Jan

yes its interesting stuff, i first learned of regular expressions when i read 'oreilly - bash in a nutshell', i knew it was some way of using patterns to match text, but i didnt really take it all in.

the term 'regular expression' didnt help either!

thanks to Matthew et al ive got a better handle on it (although i still dont fully understand it, and i suppose its what matthew was saying, you have to practice and read, practice and re-read.)

a big problem for me was realizing that the shell works in its own way and may misinterpret the regular expression if the user was not careful, hence the need for quoting etc.

the other problem i have is difficult to explain, but its regarding structure of commandlines etc, its hazy at the moment, but with each good explaination i understand a little more

oh ho!!! while searching through Man pages,theory & linuxquestions.org
I have realised that,there are things like
1. Wildcard characters, which have been popularly used in DOS
2.There are regular expressions as taught in subjects like Theory of Computational Science.
3. There are also, Extended regular expressions(R.E.).
4. There is Pattern Matching which looks very similar to R.E. but, which are not.
5. And, finally there is Perl-style regular expressions.

Oh GOD!! Save Me. What should I learn??