GNU bug report logs - #36764
grep -q throwing up No such file or directory error

Previous Next

Package: grep;

Reported by: Lewis Farnworth <lewfar99 <at> gmail.com>

Date: Mon, 22 Jul 2019 17:54:02 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36764 in the body.
You can then email your comments to 36764 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-grep <at> gnu.org:
bug#36764; Package grep. (Mon, 22 Jul 2019 17:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lewis Farnworth <lewfar99 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-grep <at> gnu.org. (Mon, 22 Jul 2019 17:54:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lewis Farnworth <lewfar99 <at> gmail.com>
To: bug-grep <at> gnu.org
Subject: grep -q throwing up No such file or directory error
Date: Mon, 22 Jul 2019 18:12:10 +0100
[Message part 1 (text/plain, inline)]
Hello,

Never posted a bug report before but I'm certain that the -q flag for grep
is broken.

I previously had a working script, that used -q in this context here:

if grep -q "RewriteCond %{HTTP_REFERER} !.*example.com*" $line; then

-----------------------------------------------------------------------------------------------------
That syntax was perfectly functioning as a conditional inside of a while
loop, to detect a colleague's error inside of a bunch of .htaccess rules.

I ran it and got what I wanted to work.

That was a few weeks back, since then I have ran a yum update (on CentOS 7)
and tried to adopt the same flag in a different script... To no avail.

This time, I'm trying to basically ascertain which servers on a given
domain are using Gmail. I've ran some dig, grep, sed & awk to ascertain a
list of mail servers the domain is using. One of the outputs which I'm
looking for looks something like this:

$   echo $mailServ:
alt3.aspmx.l.google.com.
alt4.aspmx.l.google.com.
alt1.aspmx.l.google.com.
alt2.aspmx.l.google.com.
aspmx.l.google.com.

*The script I'm running:*

if grep -q "google.com" $mailServ; then
printf "%s uses google for mail \n" $mailServ
fi

I've run into a few weird error messages when trying to use the -q
option... And I'm 100% certain that this is not a syntax issue (but there's
a part of me wishing it is).

*The error I get is: *

grep: aspmx.l.google.com.: No such file or directory
grep: alt1.aspmx.l.google.com.: No such file or directory
grep: alt4.aspmx.l.google.com.: No such file or directory
grep: alt2.aspmx.l.google.com.: No such file or directory
grep: alt3.aspmx.l.google.com.: No such file or directory

When in actual fact, all I need is the  printf command output. I tried to
run the exact same script on Debian 9, to ensure that was not the issue...
Apparently that doesn't work either.

I ran an individual grep command (no flags) on text file with the exact
same contents.
It came back with positives, as you'd expect... as every line had the word
google in there.

I tried to use the first script I wrote again, for the sake of a sanity
check, and that script is now broken too.

To reiterate:

if grep -q "thing_i'm_looking_for" $variable_i'm_looking_in; then

doesn't work, on CentOS 7 or Debian 9.  I have tried putting the variable
in single and double quotes, putting the thing I'm looking for in single
and double quotes, putting the if parameters inside square brackets,
exporting the variable to a text file and grepping from that and using the
-s flag... Please can someone take a look and check that I'm not insane and
that this infact a bug and not my own problem.

GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)

Kind regards,
Lewis
[Message part 2 (text/html, inline)]

Information forwarded to bug-grep <at> gnu.org:
bug#36764; Package grep. (Mon, 22 Jul 2019 22:17:02 GMT) Full text and rfc822 format available.

Message #8 received at 36764 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Lewis Farnworth <lewfar99 <at> gmail.com>
Cc: 36764 <at> debbugs.gnu.org
Subject: Re: bug#36764: grep -q throwing up No such file or directory error
Date: Mon, 22 Jul 2019 16:16:43 -0600
tag 36764 notabug
close 36764
stop

Hello,

(answering out-of-order)

On Mon, Jul 22, 2019 at 06:12:10PM +0100, Lewis Farnworth wrote:

> To reiterate:
> 
> if grep -q "thing_i'm_looking_for" $variable_i'm_looking_in; then
> 
> doesn't work, on CentOS 7 or Debian 9.

This is incorrect usage, and has never worked with gnu grep.
The correct usage is:

   grep -q "thing_i'm_looking_for" "FILE to look in"

Or, to check the content of a variable, use:

   echo "$variable_i'm_looking_in" | grep -q "$thing_i'm_looking_for"

or the more robust:

   printf "%s" "$variable_i'm_looking_in" | grep -q "$thing_i'm_looking_for"

> I previously had a working script, that used -q in this context here:
> 
> if grep -q "RewriteCond %{HTTP_REFERER} !.*example.com*" $line; then
> 
> -----------------------------------------------------------------------------------------------------
> That syntax was perfectly functioning as a conditional inside of a while
> loop, to detect a colleague's error inside of a bunch of .htaccess rules.

As for the above, I would guess that the "while" loop read a FILENAME
into the variable $line (e.g. a path of an .htaccess file),
and then grep would search for the pattern in that file.

If you have access to the machine where the above works,
add "echo LINE=$line" to print the content of the variable,
and you'll see it contains a file name.


> This time, I'm trying to basically ascertain which servers on a given
> domain are using Gmail. I've ran some dig, grep, sed & awk to ascertain a
> list of mail servers the domain is using. One of the outputs which I'm
> looking for looks something like this:
> 
> $   echo $mailServ:
> alt3.aspmx.l.google.com.
> alt4.aspmx.l.google.com.
> alt1.aspmx.l.google.com.
> alt2.aspmx.l.google.com.
> aspmx.l.google.com.
> 
> *The script I'm running:*
> 
> if grep -q "google.com" $mailServ; then
> printf "%s uses google for mail \n" $mailServ
> fi
> 
> I've run into a few weird error messages when trying to use the -q
> option... And I'm 100% certain that this is not a syntax issue (but there's
> a part of me wishing it is).
> 
> *The error I get is: *
> 
> grep: aspmx.l.google.com.: No such file or directory
> grep: alt1.aspmx.l.google.com.: No such file or directory
> grep: alt4.aspmx.l.google.com.: No such file or directory
> grep: alt2.aspmx.l.google.com.: No such file or directory
> grep: alt3.aspmx.l.google.com.: No such file or directory

This is expected, as explained above.

> When in actual fact, all I need is the  printf command output. I tried to
> run the exact same script on Debian 9, to ensure that was not the issue...
> Apparently that doesn't work either.

Use something like:

  if echo "$mailServ" | grep -q "google.com"; then
     printf "%s uses google for mail \n" $mailServ
  fi

Note that this operates on the entire content of "$mailServ" (all lines
together), not line-by-line.


> I tried to use the first script I wrote again, for the sake of a sanity
> check, and that script is now broken too.

If an unmodified script used to work on CentOS before an upgrade,
and stops working after the upgrade (again, unmodified),
and you've isolated the issue to grep, please provide more details
(e.g. the entire script).

As such, I'm closing this as "not a bug", but discussion can continue
by replying to this thread.

regards,
 - assaf

P.S.
Note that in your regex patterns you use "." as a literal dot,
but it is in fact a regex special character meaning "any character".
So:

     grep "google.com" $FILE

would also match a file containing "googleXcom".

To match a literal dot, use "\.".




Added tag(s) notabug. Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 22 Jul 2019 22:17:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 36764 <at> debbugs.gnu.org and Lewis Farnworth <lewfar99 <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 22 Jul 2019 22:17:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-grep <at> gnu.org:
bug#36764; Package grep. (Wed, 24 Jul 2019 06:37:02 GMT) Full text and rfc822 format available.

Message #15 received at 36764 <at> debbugs.gnu.org (full text, mbox):

From: Stephane Chazelas <stephane.chazelas <at> gmail.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 36764 <at> debbugs.gnu.org, Lewis Farnworth <lewfar99 <at> gmail.com>
Subject: Re: bug#36764: grep -q throwing up No such file or directory error
Date: Wed, 24 Jul 2019 07:36:32 +0100
2019-07-22 16:16:43 -0600, Assaf Gordon:
[...]
> or the more robust:
> 
>    printf "%s" "$variable_i'm_looking_in" | grep -q "$thing_i'm_looking_for"
[...]

Preferably (POSIXly):

printf "%s\n" "$variable_i'm_looking_in" | grep -qe "$thing_i'm_looking_for"

Or

printf "%s\n" "$variable_i'm_looking_in" | grep -q -- "$thing_i'm_looking_for"

That is add a newline character so grep's input is valid text
and guard against "$thing_i'm_looking_for" starting with -.

[...]
> Use something like:
> 
>   if echo "$mailServ" | grep -q "google.com"; then
>      printf "%s uses google for mail \n" $mailServ
>   fi
[...]

Note that it matches on googleXcom as well as "." is a regexp
operator (I see you made that note later one). Use grep -q
'google\.com' or grep -Fq google.com, but better here would be
to use a case statement and drop grep altogether:

case $mailServ in
  (*google.com*)
    printf '%s uses google for mail\n' "$mailServ"
esac

-- 
Stephane




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 21 Aug 2019 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 242 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.