From: L A Walsh <cygwin@tlinx.org>
To: cygwin@cygwin.com
Subject: Re: Bug in 'grep'ing for string in /proc/registry...
Date: Mon, 07 Sep 2020 07:02:13 -0700 [thread overview]
Message-ID: <5F563D65.5000307@tlinx.org> (raw)
In-Reply-To: <758d674d-7501-56ea-7246-894e5c877778@SystematicSw.ab.ca>
On 9/7/2020 12:05 AM, Brian Inglis wrote:
>> /bin/grep -Pr '\.dll'
>> /bin/grep: Group: Is a directory
>> /bin/grep: ImagePath: Is a directory
----
ImagePath is a expandable string value under the Eventlog
key. 'ls -l' shows ImagePath has having 65 bytes.
> ll ImagePath
-r--r----- 1 65 Sep 6 22:06 ImagePath
Reading the contents, one gets:
>>> read -r x <ImagePath
>>> echo $x
>> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
>> whose length is ${#x} = 64 (not counting end-of-string)
> You remember that the /proc/registry.../ entries are only the
> keys, subkeys, and kk values names, not the data contained in them.
---
Not exactly. Keys are the fs-equivalent of directories,
subkeys are the equivalent of subdirectories, and values are filenames
that usually contain content. Any util that would normally read
file-content (or scan through it, like grep) will read the content in
registry values.
> You are doing the equivalent of:
> $ fgrep -r .dll
---
Correct. Which is almost the same as
fgrep -r .dll .
with the difference that results with the "." will have a "./" on
the front of the names, i.e.
>> /bin/fgrep -r .dll .
>> /bin/fgrep: ./Group: Is a directory
>> /bin/fgrep: ./ImagePath: Is a directory
----
I'm not sure, but it looks like you may be confusing
the function & output of 'find' and grep? Where find looks only
at the names, whereas 'grep' scans for the text string in the
content of the files. Given the '-r' param, 'grep' will descend
into directories -- not attempt to scan them as text files.
> producing nothing but error messages.
---
Normally text files are not classified as directories.
Both 'ls' and 'bash' classify keys as 'directories', while values,
of every sort are classified as files.
linda
prev parent reply other threads:[~2020-09-07 14:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 5:34 Weird behavior " L A Walsh
2020-09-07 7:05 ` Brian Inglis
2020-09-07 7:53 ` Thomas Wolff
2020-09-07 19:15 ` Brian Inglis
2020-09-07 20:51 ` Corinna Vinschen
2020-09-07 21:34 ` cygwin1.dll: uname_x not found L A Walsh
2020-09-08 7:18 ` Corinna Vinschen
2020-09-08 18:28 ` L A Walsh
2020-09-08 18:47 ` Thomas Wolff
2020-09-08 19:21 ` Corinna Vinschen
2020-09-08 19:21 ` Corinna Vinschen
2020-09-08 19:25 ` Corinna Vinschen
2020-09-07 14:02 ` L A Walsh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5F563D65.5000307@tlinx.org \
--to=cygwin@tlinx.org \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).