* Weird behavior in 'grep'ing for string in /proc/registry... @ 2020-09-07 5:34 L A Walsh 2020-09-07 7:05 ` Brian Inglis 0 siblings, 1 reply; 13+ messages in thread From: L A Walsh @ 2020-09-07 5:34 UTC (permalink / raw) To: cygwin In directory /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog I wanted to list all the ".dll"s that handled various types of events. I tried /bin/grep -Pr '\.dll' but got a load of bogus error messages: /bin/grep: Group: Is a directory /bin/grep: ImagePath: Is a directory /bin/grep: Description: Is a directory /bin/grep: ObjectName: Is a directory .... --- looking at ImagePath: > ll ImagePath -r--r----- 1 65 Sep 6 22:06 ImagePath > read -r x <ImagePath > echo $x C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted --- Doesn't look like a directory. So, bug in 'grep'? I'm hoping this isn't limited to my machine... Thanks! linda ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Weird behavior in 'grep'ing for string in /proc/registry... 2020-09-07 5:34 Weird behavior in 'grep'ing for string in /proc/registry L A Walsh @ 2020-09-07 7:05 ` Brian Inglis 2020-09-07 7:53 ` Thomas Wolff 2020-09-07 14:02 ` Bug in 'grep'ing for string in /proc/registry L A Walsh 0 siblings, 2 replies; 13+ messages in thread From: Brian Inglis @ 2020-09-07 7:05 UTC (permalink / raw) To: cygwin On 2020-09-06 23:34, L A Walsh wrote: > In directory > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog > I wanted to list all the ".dll"s that handled various types of > events. > > I tried > /bin/grep -Pr '\.dll' > > but got a load of bogus error messages: > > /bin/grep: Group: Is a directory > /bin/grep: ImagePath: Is a directory > /bin/grep: Description: Is a directory > /bin/grep: ObjectName: Is a directory > .... > > --- > looking at ImagePath: >> ll ImagePath > -r--r----- 1 65 Sep 6 22:06 ImagePath >> read -r x <ImagePath >> echo $x > C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted > > --- > Doesn't look like a directory. > So, bug in 'grep'? > > I'm hoping this isn't limited to my machine... You remember that the /proc/registry.../ entries are only the keys, subkeys, and values names, not the data contained in them. You are doing the equivalent of: $ fgrep -r .dll /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ 2> /dev/null producing nothing but error messages. What you probably want to do is check for the keys, subkeys, and values data containing .dll names, which is best performed with find and regtool: $ find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ -type d -print0 | xargs -0 -l1 regtool list -v | fgrep .dll DisplayNameFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\ieframe.dll" CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll" ...[90]... EventMessageFile (REG_SZ) = "C:\Windows\SysWOW64\msvbvm60.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\sdengin2.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" CategoryMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wsepno.dll" EventMessageFile (REG_SZ) = "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\ntvdm64.dll" EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wshext.dll" or you could use the Windows reg command directly for more verbose results: $ reg query HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application /s /d /f "*.dll" HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application DisplayNameFile REG_EXPAND_SZ %SystemRoot%\system32\wevtapi.dll HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET Runtime EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET Runtime Optimization Service EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll ...[104]... HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WMI.NET Provider Extension EventMessageFile REG_SZ C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\Wow64 Emulation Layer EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\ntvdm64.dll HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WSH EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\wshext.dll End of search: 110 match(es) found. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Weird behavior in 'grep'ing for string in /proc/registry... 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 14:02 ` Bug in 'grep'ing for string in /proc/registry L A Walsh 1 sibling, 2 replies; 13+ messages in thread From: Thomas Wolff @ 2020-09-07 7:53 UTC (permalink / raw) To: cygwin Am 07.09.2020 um 09:05 schrieb Brian Inglis: > On 2020-09-06 23:34, L A Walsh wrote: >> In directory >> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog >> I wanted to list all the ".dll"s that handled various types of >> events. >> >> I tried >> /bin/grep -Pr '\.dll' >> >> but got a load of bogus error messages: >> >> /bin/grep: Group: Is a directory >> /bin/grep: ImagePath: Is a directory >> /bin/grep: Description: Is a directory >> /bin/grep: ObjectName: Is a directory >> .... >> >> --- >> looking at ImagePath: >>> ll ImagePath >> -r--r----- 1 65 Sep 6 22:06 ImagePath >>> read -r x <ImagePath >>> echo $x >> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted >> >> --- >> Doesn't look like a directory. >> So, bug in 'grep'? >> >> I'm hoping this isn't limited to my machine... > You remember that the /proc/registry.../ entries are only the keys, subkeys, and > values names, not the data contained in them. > > You are doing the equivalent of: > > $ fgrep -r .dll > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ > 2> /dev/null > > producing nothing but error messages. I reproduced Lindas observation (although not in the folder she mentioned which does not exist here) and in fact there is an inconsistency between `grep -r` reporting "Is a directory" for entries that are not marked as directory by `ls`: .pwd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Appinfo/Parameters .ls -l insgesamt 0 -r--r----- 1 SYSTEM SYSTEM 34 27. Nov 2019 ServiceDll -r--r----- 1 SYSTEM SYSTEM 4 27. Nov 2019 ServiceDllUnloadOnStop .grep -r . grep: ServiceDll: Is a directory grep: ServiceDllUnloadOnStop: Is a directory I checked whether `opendir` marks the d_type fields wrong in the /proc filesystem but that's not it. Thomas > > What you probably want to do is check for the keys, subkeys, and values data > containing .dll names, which is best performed with find and regtool: > > $ find > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ > -type d -print0 | xargs -0 -l1 regtool list -v | fgrep .dll > DisplayNameFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" > EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" > EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" > CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" > CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\ieframe.dll" > CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll" > ...[90]... > EventMessageFile (REG_SZ) = "C:\Windows\SysWOW64\msvbvm60.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" > EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\sdengin2.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" > CategoryMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" > EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wsepno.dll" > EventMessageFile (REG_SZ) = > "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\ntvdm64.dll" > EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wshext.dll" > > or you could use the Windows reg command directly for more verbose results: > > $ reg query > HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application > /s /d /f "*.dll" > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application > DisplayNameFile REG_EXPAND_SZ %SystemRoot%\system32\wevtapi.dll > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET > Runtime > EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET > Runtime Optimization Service > EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll > > ...[104]... > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WMI.NET Provider > Extension > EventMessageFile REG_SZ > C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\Wow64 > Emulation Layer > EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\ntvdm64.dll > > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WSH > EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\wshext.dll > > End of search: 110 match(es) found. > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Weird behavior in 'grep'ing for string in /proc/registry... 2020-09-07 7:53 ` Thomas Wolff @ 2020-09-07 19:15 ` Brian Inglis 2020-09-07 20:51 ` Corinna Vinschen 1 sibling, 0 replies; 13+ messages in thread From: Brian Inglis @ 2020-09-07 19:15 UTC (permalink / raw) To: cygwin On 2020-09-07 01:53, Thomas Wolff wrote: > Am 07.09.2020 um 09:05 schrieb Brian Inglis: >> On 2020-09-06 23:34, L A Walsh wrote: >>> In directory >>> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog >>> I wanted to list all the ".dll"s that handled various types of >>> events. >>> >>> I tried >>> /bin/grep -Pr '\.dll' >>> >>> but got a load of bogus error messages: >>> >>> /bin/grep: Group: Is a directory >>> /bin/grep: ImagePath: Is a directory >>> /bin/grep: Description: Is a directory >>> /bin/grep: ObjectName: Is a directory >>> .... >>> >>> --- >>> looking at ImagePath: >>>> ll ImagePath >>> -r--r----- 1 65 Sep 6 22:06 ImagePath >>>> read -r x <ImagePath >>>> echo $x >>> C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted >>> >>> --- >>> Doesn't look like a directory. >>> So, bug in 'grep'? >>> >>> I'm hoping this isn't limited to my machine... >> You remember that the /proc/registry.../ entries are only the keys, subkeys, and >> values names, not the data contained in them. >> >> You are doing the equivalent of: >> >> $ fgrep -r .dll >> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ >> >> 2> /dev/null >> >> producing nothing but error messages. > I reproduced Lindas observation (although not in the folder she mentioned which > does not exist here) and in fact there is an inconsistency between `grep -r` > reporting "Is a directory" for entries that are not marked as directory by `ls`: > .pwd > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Appinfo/Parameters > > .ls -l > insgesamt 0 > -r--r----- 1 SYSTEM SYSTEM 34 27. Nov 2019 ServiceDll > -r--r----- 1 SYSTEM SYSTEM 4 27. Nov 2019 ServiceDllUnloadOnStop > .grep -r . > grep: ServiceDll: Is a directory > grep: ServiceDllUnloadOnStop: Is a directory > > I checked whether `opendir` marks the d_type fields wrong in the /proc > filesystem but that's not it. I believe we are seeing that the registry fs virtualization is insufficient for grep and some other utilities to differentiate, so they are complaining, not descending and searching. So you can do what you want using: $ find /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ -type f -print0 | xargs -0 fgrep -a .dll but you need the -a as the file contents appear as binary strings with NUL char terminators (and these appear in the output), not text files with \n terminators. My alternatives convert the values and data to text on lines which you can search with clean results. You could strace your problematic searches and post along with cygcheck.out and hope someone has time to dig in and debug the issue. >> What you probably want to do is check for the keys, subkeys, and values data >> containing .dll names, which is best performed with find and regtool: >> >> $ find >> /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog/Application/ >> >> -type d -print0 | xargs -0 -l1 regtool list -v | fgrep .dll >> DisplayNameFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" >> EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" >> EventMessageFile (REG_SZ) = "C:\Windows\System32\mscoree.dll" >> CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wevtapi.dll" >> CategoryMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\ieframe.dll" >> CategoryMessageFile (REG_EXPAND_SZ) = >> "%SystemRoot%\System32\drivers\ati2erec.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\drivers\ati2erec.dll" >> ...[90]... >> EventMessageFile (REG_SZ) = "C:\Windows\SysWOW64\msvbvm60.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wersvc.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\sdengin2.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wer.dll" >> CategoryMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%systemroot%\system32\tquery.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\system32\wsepno.dll" >> EventMessageFile (REG_SZ) = >> "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\ntvdm64.dll" >> EventMessageFile (REG_EXPAND_SZ) = "%SystemRoot%\System32\wshext.dll" >> >> or you could use the Windows reg command directly for more verbose results: >> >> $ reg query >> HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\eventlog\\Application >> /s /d /f "*.dll" >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application >> DisplayNameFile REG_EXPAND_SZ %SystemRoot%\system32\wevtapi.dll >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET >> Runtime >> EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\.NET >> Runtime Optimization Service >> EventMessageFile REG_SZ C:\Windows\System32\mscoree.dll >> >> ...[104]... >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WMI.NET >> Provider >> Extension >> EventMessageFile REG_SZ >> C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\Wow64 >> Emulation Layer >> EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\ntvdm64.dll >> >> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\WSH >> EventMessageFile REG_EXPAND_SZ %SystemRoot%\System32\wshext.dll >> >> End of search: 110 match(es) found. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Weird behavior in 'grep'ing for string in /proc/registry... 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 1 sibling, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2020-09-07 20:51 UTC (permalink / raw) To: cygwin On Sep 7 09:53, Thomas Wolff wrote: > Am 07.09.2020 um 09:05 schrieb Brian Inglis: > > On 2020-09-06 23:34, L A Walsh wrote: > > > In directory > > > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/eventlog > > > I wanted to list all the ".dll"s that handled various types of > > > events. > > > > > > I tried > > > /bin/grep -Pr '\.dll' > > > > > > but got a load of bogus error messages: > > > > > > /bin/grep: Group: Is a directory > > > /bin/grep: ImagePath: Is a directory > > > /bin/grep: Description: Is a directory > > > /bin/grep: ObjectName: Is a directory > > > .... > > [...] > I reproduced Lindas observation (although not in the folder she mentioned > which does not exist here) and in fact there is an inconsistency between > `grep -r` reporting "Is a directory" for entries that are not marked as > directory by `ls`: > .pwd > /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Appinfo/Parameters > .ls -l > insgesamt 0 > -r--r----- 1 SYSTEM SYSTEM 34 27. Nov 2019 ServiceDll > -r--r----- 1 SYSTEM SYSTEM 4 27. Nov 2019 ServiceDllUnloadOnStop > .grep -r . > grep: ServiceDll: Is a directory > grep: ServiceDllUnloadOnStop: Is a directory > > I checked whether `opendir` marks the d_type fields wrong in the /proc > filesystem but that's not it. No, it's a collision of an internal flag with an official open(2) flag from fcntl.h, used by grep in this case. I changed the way the internal flag is used so it doesn't collide with fcntl.h flags ever, even if we add some more. I uploaded new snapshots for testing to https://cygwin.com/snapshots/ Please give them a try. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 13+ messages in thread
* cygwin1.dll: uname_x not found 2020-09-07 20:51 ` Corinna Vinschen @ 2020-09-07 21:34 ` L A Walsh 2020-09-08 7:18 ` Corinna Vinschen 0 siblings, 1 reply; 13+ messages in thread From: L A Walsh @ 2020-09-07 21:34 UTC (permalink / raw) To: cygwin > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > Please give them a try. --- Got: "The procedure entry point uname_x could not be located in the dynamic link library cygwin1.dll" :-( ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 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 0 siblings, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2020-09-08 7:18 UTC (permalink / raw) To: cygwin On Sep 7 14:34, L A Walsh wrote: > > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > > > Please give them a try. > --- > Got: > > "The procedure entry point uname_x could not be located in the dynamic > link library cygwin1.dll" > > :-( uname_x is exported just fine. You're doing something wrong. Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 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 0 siblings, 2 replies; 13+ messages in thread From: L A Walsh @ 2020-09-08 18:28 UTC (permalink / raw) To: cygwin On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > On Sep 7 14:34, L A Walsh wrote: >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ >>> >>> Please give them a try. >> --- >> Got: >> >> "The procedure entry point uname_x could not be located in the dynamic >> link library cygwin1.dll" > > uname_x is exported just fine. You're doing something wrong. > > Corinna --- I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. What step did I miss? Sorry, I know whatever I missed is obvious to you -- it always is obvious to someone who knows the answer, but to those that don't know the answer, it isn't at all obvious. I have used test libraries before the same way and had them work. So I don't know what I missed. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 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 1 sibling, 1 reply; 13+ messages in thread From: Thomas Wolff @ 2020-09-08 18:47 UTC (permalink / raw) To: cygwin Am 08.09.2020 um 20:28 schrieb L A Walsh: > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: >> On Sep 7 14:34, L A Walsh wrote: >>>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ >>>> >>>> Please give them a try. For me, the snapshot dll fixes the issue I observed. Thomas >>> --- >>> Got: >>> >>> "The procedure entry point uname_x could not be located in the dynamic >>> link library cygwin1.dll" >> uname_x is exported just fine. You're doing something wrong. >> >> Corinna > --- > I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll > to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. > > What step did I miss? > > Sorry, I know whatever I missed is obvious to you -- it always is obvious > to someone who knows the answer, but to those that don't know the answer, > it isn't at all obvious. > > I have used test libraries before the same way and had them work. So I > don't know what I missed. > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 2020-09-08 18:47 ` Thomas Wolff @ 2020-09-08 19:21 ` Corinna Vinschen 0 siblings, 0 replies; 13+ messages in thread From: Corinna Vinschen @ 2020-09-08 19:21 UTC (permalink / raw) To: cygwin On Sep 8 20:47, Thomas Wolff wrote: > > > Am 08.09.2020 um 20:28 schrieb L A Walsh: > > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > > On Sep 7 14:34, L A Walsh wrote: > > > > > I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > > > > > > > > > Please give them a try. > For me, the snapshot dll fixes the issue I observed. Thanks for testing and confirming, Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 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:25 ` Corinna Vinschen 1 sibling, 1 reply; 13+ messages in thread From: Corinna Vinschen @ 2020-09-08 19:21 UTC (permalink / raw) To: cygwin On Sep 8 11:28, L A Walsh wrote: > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > On Sep 7 14:34, L A Walsh wrote: > >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > >>> > >>> Please give them a try. > >> --- > >> Got: > >> > >> "The procedure entry point uname_x could not be located in the dynamic > >> link library cygwin1.dll" > > > > uname_x is exported just fine. You're doing something wrong. > > > > Corinna > --- > I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll > to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. > > What step did I miss? > > Sorry, I know whatever I missed is obvious to you -- it always is obvious > to someone who knows the answer, but to those that don't know the answer, > it isn't at all obvious. No, it's not at all obvious to me what you did wrong. Still, the snapshot DLL works fine for me and, apparently, Thomas had no problem either. ¯\_(ツ)_/¯ Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: cygwin1.dll: uname_x not found 2020-09-08 19:21 ` Corinna Vinschen @ 2020-09-08 19:25 ` Corinna Vinschen 0 siblings, 0 replies; 13+ messages in thread From: Corinna Vinschen @ 2020-09-08 19:25 UTC (permalink / raw) To: cygwin On Sep 8 21:21, Corinna Vinschen wrote: > On Sep 8 11:28, L A Walsh wrote: > > > > > > On 9/8/2020 12:18 AM, Corinna Vinschen wrote: > > > On Sep 7 14:34, L A Walsh wrote: > > >>> I uploaded new snapshots for testing to https://cygwin.com/snapshots/ > > >>> > > >>> Please give them a try. > > >> --- > > >> Got: > > >> > > >> "The procedure entry point uname_x could not be located in the dynamic > > >> link library cygwin1.dll" > > > > > > uname_x is exported just fine. You're doing something wrong. > > > > > > Corinna > > --- > > I stopped all cygwin processes. Using cmd.exe, I renamed cygwin1.dll > > to cygwin1.dll-. I 'copy'd the new dll in place and tried to run something. > > > > What step did I miss? > > > > Sorry, I know whatever I missed is obvious to you -- it always is obvious > > to someone who knows the answer, but to those that don't know the answer, > > it isn't at all obvious. > > No, it's not at all obvious to me what you did wrong. Still, the > snapshot DLL works fine for me and, apparently, Thomas had no problem > either. Btw., if the snapshot DLL doesn't export uname_x, then you're actually using a very old DLL (pre 2.0 or so) accidentally. Corinna -- Corinna Vinschen Cygwin Maintainer ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Bug in 'grep'ing for string in /proc/registry... 2020-09-07 7:05 ` Brian Inglis 2020-09-07 7:53 ` Thomas Wolff @ 2020-09-07 14:02 ` L A Walsh 1 sibling, 0 replies; 13+ messages in thread From: L A Walsh @ 2020-09-07 14:02 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-09-08 19:25 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-07 5:34 Weird behavior in 'grep'ing for string in /proc/registry 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 ` Bug in 'grep'ing for string in /proc/registry L A Walsh
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).