Re: multitail segfaults

2015-04-22 Thread John Bianchi
Subject: Re: multitail segfaults

I also have this problem when I use multitail.  

$ multitail --version
 --*- multitail 6.3 (C) 2003-2014 by folk...@vanheusden.com -*--

The following problem occured:
-
[1]10832 segmentation fault (core dumped)  multitail --version


Info:
$ uname -a
CYGWIN_NT-6.1-WOW workstation1 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 Cygwin

attached cygcheck.out

(also tested fresh using babun install)


-- Original Message --
Received: 06:51 AM MDT, 04/02/2015
From: Frank Fesevur f...@users.sourceforge.net
To: cygwin@cygwin.com cygwin@cygwin.com
Subject: multitail segfaults

 Hi,
 
 I'm experiencing a problem with multitail. It always gives a segmentation
fault.
 
 $ multitail --version
  --*- multitail 6.3 (C) 2003-2014 by folk...@vanheusden.com -*--
 
 The following problem occured:
 -
 Segmentation fault (core dumped)
 
 I see this behavior on all my installations. cygcheck -srv doesn't
 show anything special. After downgrading to the previous version
 (5.2.12) it works again.
 
 Anyone else seeing the same problem?
 
 Regards,
 Frank
 
 --
 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
 






cygcheck.out
Description: Binary data
--
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

Re: RemoteServerAdministrationTools problem

2014-06-04 Thread John Bianchi
 Aside from this set of Windows tools, can you reproduce the same behavior
 with some more commonly available and more compact utility?

I had two system exhibiting this symptom. Wish there was an official way to
install an older cygwin, like 1.7.27 or .26.  No other commands are behaving
differently that I am aware of.

I did reinstall win7 ent on my second system, installed RSAT and cygwin and
dsquery works again.  Not sure what I did in both systems to create this
problem.  I though it was Proxy32 for proxywinconsole.exe which let me go
interactive from a cygwin shell to powershell for my powershell wrapper (see
https://bitbucket.org/jbianchi/powershell) but I only installed that on my
main system.  I'll rebuild and continue to install all the utils to see what
breaks it again.

The RSAT tools give command line access to AD and lets me script so much.  I'm
blown away by how a windows admin will work so inefficiently using the Active
Directory User and Computers GUI tool.  Batch scripting is terrible and the
windows console is worse.  And don't start me on Powershell! Powershell has a
crappy console, no history retention ... how can they be valid
shells/consoles? You just dont develop ps1 scripts to call ps1 scripts to
build more powerfull utils in powershell like you do in unix.  Cygwin with
RXVT gives me a complete enough unix shell with a great console (cut and paste
anyone?).  I can script mixing powershell, dos batch and cygwin I can make
windows managable.


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



RemoteServerAdministrationTools problem

2014-06-02 Thread John Bianchi
I have in the past called the dos commands from the Remote Server
Administration Tools (RSAT) feature pack (Win7
http://www.microsoft.com/en-us/download/details.aspx?id=7887) from Cygwin's
shell.  I've spent a fair amount of time cleaning up their cruddy output and
making useful wrappers (although not complete) to these DOS tools for
cygwin/bash.

Now in Cygwin 1.7.29 and 1.7.30 they do not return any information from these
tools.  A call to dsquery.exe without args should show usage, now it returns
nothing.  
Launching cmd.exe in a cygwin shell would allow calling those tools
interactively (but not really usable) but return nothing now.

Once installed these tools are available from C:\Windows\System32\ in the
Windows System PATH and available to Cygwin inheriting that path.  I am not
pathing to the tools in these examples but directly calling it using absolute
paths does not solve the problem.

$ dsquery.exe user -name test user 
CN=Test User,OU=Users,OU=Test,DC=domain,DC=com

which you could pipe to dsget as in:
$ dsquery.exe user -name test user | dsget user -email
 email
 test.u...@domain.com
dsget succeeded

None of this works anymore in the latest Cygwins, I am not sure when it broke.
 I wrote some pretty fancy wrappers to cleanup the output and simplify calling
from cygwin which is not getting any output.  

Calling command.com directly in cygwin used to work, now just returns the
command name:
==
$ cmd
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\dsquery
dsquery

==

older cygwin worked:
==
$ cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\dsquery /?
dsquery /?
Description: This tool's commands suite allow you to query the directory
according to specified criteria. Each of the following dsquery commands finds
... snip
==

older cygwin worked fully:
==
C:\dsquery user -name test user | dsget user -email
dsquery user -name test user | dsget user -email
  email
  test.u...@domain.com  
dsget succeeded
==
a plain call w/o args will display a usage which works in older cygwins.  This
was around March/April.  1.7.29 is dated 2014-04-07 but I'm fairly sure it was
working then.  Not sure what environment settings would affect this.

I can get output in cygwin from this call but cannot pass args to this
command:
==
$ dsquery user
CN=
 snip
CN=
==
lists CNs but not all of them in lower OU's, you will need to call dsquery
w/args for that.

I don't think I can get an older cygwin (1.7.28?) installed to see if it was a
change there.  I've tried RXVT and mintty in cygwin with the same behavior. 
Most my tests from old cygwin is an instance older than the 32/64 bit split
but I know I had it working a month or so ago in cygwin 32bit.

Attached cygcheck output



cygcheck.out
Description: Binary data
--
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

Re: RemoteServerAdministrationTools problem

2014-06-02 Thread John Bianchi
 On 06/02/2014 07:09 PM, John Bianchi wrote:
 
 snip
 
  I can get output in cygwin from this call but cannot pass args to this
  command:
  ==
  $ dsquery user
  CN=
   snip
  CN=
  ==
  lists CNs but not all of them in lower OU's, you will need to call
dsquery
  w/args for that.
 
 Sounds a bit like https://sourceware.org/ml/cygwin/2014-02/msg00334.html
 to me.  Take a look at the entire thread and the reference to the original
 patch that began this journey.
 
 -- 
 Larry
 

I've tried Cygwin 64bit 1.7.30 and the commands work like they used to in 32
bit Cygwin.

Not sure if the thread you provided covers this as there is no = passed
here. I also dont call cmd.exe as I call the dsquery.exe directly in a cygwin
bash sehll.  Was there other changes made that affect this?  Reading that
thread seems the changes are made ... no talk of reverting... so is 64 bit
gonna get broken next?  Why isn't 64 bit the same, ie have the same problem?
Shouldn't they be the same? Did that change not get made in the 64 bit version
of cygwin?

John


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