DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=HoBOFXQRwpiiS99U
	zQXxr5eMgWnlDKbiudHeHhHgVKD3nxgFWcXzZYpH9Lopbsve1SS2UW38x9E5b7fO
	UHfkFDSNFkD0nWvN23Fuv8NK2o14DOOM58+icjRaVrmqlI2/U+Expi63XE0jUhIi
	PXmqgBuMd46I8iIrIxXAiurMcpQ=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Sat, 18 Apr 2015 02:00:33 +0300
From: Andrey Repin <anrdaemon@yandex.ru>
Reply-To: cygwin@cygwin.com
Message-ID: <1638654029.20150418020033@yandex.ru>
To: Keith Christian <keith1christian@gmail.com>, cygwin@cygwin.com
Subject: Re: dig utility in bind-utils-9.9.7-1 returns no output
In-Reply-To: <CAFWoy7EowK6mkAvEmgbNMdDVvf_vieyaWmhm8XLQKJJmyYeA9A@mail.gmail.com>
References: <CAFWoy7F6DMy4L8ccwOSztuJfKqPhkVW9TTsL2ZEBjvum-6hYsg@mail.gmail.com>   <CAFWoy7HKNuz8_nj9iHamGXzxvcFx-mtOSRPQJqn2OxGOpAmLmg@mail.gmail.com>  <1923978077.20150414135419@yandex.ru>  <CAFWoy7HGJSXhvjBraTqrw_XZ+6+JQFhJkrfANNGhz4wrXgQ=JQ@mail.gmail.com>  <552D7120.9000409@gmail.com>  <CAFWoy7FuWgcpOsv+fnC_wbrrx8rLJY8KcW86+kBJDzDFEoSuQw@mail.gmail.com>  <552D8C5E.2020208@winfirst.com>  <CAFWoy7FxE_jDKYLx_SNKayzzHOvr_BQb72WtFEQCXfApax0viQ@mail.gmail.com>  <CAFWoy7HVZt8cTy5wpry+o4FrFTnJSYET1FEZCWL5Jnp7E7QNEw@mail.gmail.com>  <552ECFAC.7040003@winfirst.com>  <CAFWoy7HftTvrBM2VxT1fxBsit7u-4gi4wnWCx56P6Ls_S8FU4g@mail.gmail.com>  <CAFWoy7EowK6mkAvEmgbNMdDVvf_vieyaWmhm8XLQKJJmyYeA9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings, Keith Christian!

>>> I'm sorry - I could be completely off-base here. What I meant was can you
>>> try running
>>> '/usr/bin/dig' (providing the full path to the application) rather than by
>>> just running 'dig'
>>> just in case there is some other 'dig' on your path (or shell aliases) which
>>> might be running
>>> rather than the actual /usr/bin/dig command.
>>>
>>> In previous messages, your examples were running 'dig' (without the full
>>> path) so it wasn't
>>> clear which dig you were actually getting.

>> Thanks Mark, but I tried both of those early in my attempts without
>> success.  Good suggestion, though.


> I updated Cygwin this morning, and now: "dig works!  I have no idea why!"

> "cksum /usr/bin/dig /bin/dig" reports the same checksums as before,
> and "cygcheck dig" produces the same output as before.

> Baffling.

I've seen similar effect, when Cygwin was going through implementation of some
specific POSIX calls, and export tables were bouncing around libs in the
snapshots.
But your claim that you've had Cygwin updated led the discussion sideways.
My bet was you've had Cygwin1.dll locked when updating and the update wasn't
completely successful.

> Thanks to all of you for the suggestions.

No problem.
However, please don't top-post in future.


-- 
With best regards,
Andrey Repin
Saturday, April 18, 2015 01:55:23

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple