Re: asterisk in regular expressions



On August 23, 2010 02:04, in comp.unix.questions, ben+unix@xxxxxxxxxxxxxxxx
wrote:

harums <struchki@xxxxxxxxx> writes:

sys1:~$ echo "now" | grep [w]*

yield "now" and command

sys1:~$ echo "now" | grep [n]*

yields nothing? Shouldn't they both give the same output?

Remember that the shell will do glob expansion *before* invoking any of
the commands. The brackets ‘[]’ and asterisk ‘*’ are all globbing
characters to the shell. The arguments to ‘grep’ will depend on what
expansion resulted from those globs.

Remember also that, should the shell not find any matches for it's globbing,
it returns the globbing string.

Note the behaviour in the following example.

The directory is initially empty
~/tmp $ ls
~/tmp $ echo *
*
and 'echo *' echoes an asterisk. But, populate the directory with a file,
~/tmp $ touch abc
~/tmp $ echo *
abc
~/tmp $
and 'echo *' now echoes the filename.

Assume in the OP's ~ directory that there are no files that match '[w]*',
and there are files that match '[n]*', but none of those files are
called "now".

Then,
sys1:~$ echo "now" | grep [w]*
will
- echo "now" to stdout
- glob '[w]*' matches no existing file in ~, so defaults to '[w]*'
- grep successfully matches the stdin string "now" to the regexp '[w]*'

OTOH,
sys1:~$ echo "now" | grep [n]*
will
- echo "now" to stdout
- glob '[n]*' matches an existing filename, and that filename is
substituted into the grep commandline
- grep unsuccessfully matches the stdin string "now" to the file name list
derived from the expansion of the regexp '[n]*' within the CWD.

To test this theory, let's try another example.

Again, we start with an empty directory, and try the OP's regexp
~/tmp $ ls
~/tmp $ echo "now" | grep [w]*
now
and we get the OP's results.

Now, let's create an appropriately named file in the directory
~/tmp $ touch wood
~/tmp $ ls
wood

and try the test again
~/tmp $ echo "now" | grep [w]*
~/tmp $
Now we see the OP's second (to him, aberant) results.

Let's see what grep sees in this second example...
~/tmp $ echo grep [w]*
grep wood
~/tmp $

So, in the 1st example, grep is given a regexp that it can match to the
input data, and succeeds. But, in the 2nd example, grep is given a list of
one or more string literals (filenames) that it cannot match to the input
data, thus it fails.

HTH
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------


.



Relevant Pages

  • Re: Ada.Command_Line and wildcards
    ... One criterion is the number of wildcard expansion surprises. ... $ echo *.ads # argument text is a pattern ... the expansion (in the shell!) has: ...
    (comp.lang.ada)
  • Re: Questions related to - Arg list too long - error
    ... I'm expecting printf or echo to fail, given that initially, there is ... wild card expansion done for them too, same as ls and friends, but no ... The shell may be able to handle the full wildcard ...
    (comp.unix.shell)
  • Re: Questions related to - Arg list too long - error
    ... I'm expecting printf or echo to fail, given that initially, there is ... wild card expansion done for them too, same as ls and friends, but no ...  The shell may be able to handle the full wildcard ... The shell does the wildcard expansion, ...
    (comp.unix.shell)
  • Re: test if
    ... command substitution... ... you can just run the command, the shell will ... if echo passwd.txt | grep -q NOT_PASSWD ...
    (comp.unix.aix)
  • Re: Match the full stop and quotation mark literally with regexp by using egrep.
    ... special meaning to grep (but not to the shell). ... that printf is substantially more portable-and-stable than echo. ...
    (comp.unix.shell)