Weird behavior in 'grep'ing for string in /proc/registry...

Weird behavior in 'grep'ing for string in /proc/registry...

[L A Walsh]

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

Re: Weird behavior in 'grep'ing for string in /proc/registry...

[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.

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.]

Re: Weird behavior in 'grep'ing for string in /proc/registry...

[Thomas Wolff]

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.
>

Re: Bug in 'grep'ing for string in /proc/registry...

[L A Walsh]

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

Re: Weird behavior in 'grep'ing for string in /proc/registry...

[Brian Inglis]

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.]

Re: Weird behavior in 'grep'ing for string in /proc/registry...

[Corinna Vinschen]

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

cygwin1.dll: uname_x not found

[L A Walsh]

> 
> 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"

:-(

Re: cygwin1.dll: uname_x not found

[Corinna Vinschen]

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

Re: cygwin1.dll: uname_x not found

[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.
>> ---
>> 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.

Re: cygwin1.dll: uname_x not found

[Thomas Wolff]

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

Re: cygwin1.dll: uname_x not found

[Corinna Vinschen]

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

Re: cygwin1.dll: uname_x not found

[Corinna Vinschen]

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

Re: cygwin1.dll: uname_x not found

[Corinna Vinschen]

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