On 4 April 2011 06:44, Daniel Colascione wrote:
> Attached is a small program that runs a set of processes under an NT job
> object, allowing you to stop, resume, and kill them using normal Cygwin
> job control --- whether or not these processes are Cygwin programs.
Very nice. One issue I frequent
Hi all,
After updating cygwin to the newest version after 3 Month I get a strange error
if I start the Xwindow with bash as usual
/bin/find: `standard output': Bad file descriptor
/bin/find: Schreibfehler.
I can trace that to the attempt of /etc/profile to read /etc/profile.d
# Run all of the
Hi all,
the error only shows up if I start from a network drive.(Netware)
If I modify /etc/profile like
MYPWD=$(pwd);
cd /cygdrive/c
[ do stuff...]
cd $MYPWD
everything works fine.
Norbert
> Gesendet: Montag, 4. April 2011 10:38
> Betreff: [bulk] - Strange error during /etc/profile
>
>
>
On Mon, Apr 04, 2011 at 11:02:57AM +0200, DEWI - N. Zacharias wrote:
> > After updating cygwin to the newest version after 3 Month I get a strange
> > error if I start the Xwindow with bash as usual
> >
> > /bin/find: `standard output': Bad file descriptor
> > /bin/find: Schreibfehler.
> >
> > I ca
Hi Dave,
> Von: David Sastre
> Gesendet: Montag, 4. April 2011 13:23
> Betreff: [bulk] - Re: Additional Infos: Strange error during /etc/profile
>
> On Mon, Apr 04, 2011 at 11:02:57AM +0200, DEWI - N. Zacharias wrote:
> > > After updating cygwin to the newest version after 3 Month I get a
> stra
Hallo,
it seems that mq_unlink and/or mq_open forget to close some handles (5 to be
precise).
How to test:
Execute the following code and watch the number of handles in the windows
task-manager (processes tab, you can add a column there). For me it increases
by 5 with every loop.
Tested with t
On 16/03/2011 19:37, Ryan Johnson wrote:
> On 2:59 PM, Henry S. Thompson wrote:
>> Ryan Johnson writes:
>>
>>> BTW, I found a good way to identify, if not fix, BLODA: given an app
>>> which loads no libraries at runtime -- such as 'ls' -- any dlls
>>> mentioned in /proc/$$/maps which cygcheck does
On 15/03/2011 13:53, Ryan Johnson wrote:
> All of this assumes Windows is consistent in choosing locations when conflicts
It's assumed that CreateProcess() produces the same layout, yes.
> are involved. IOW, consider the case that B depends on A, with A and B both
> conflicting with a later-loade
Grmpf,
sorry for the spam. Just realized that mq_close is still needed, even if we
don't want to open the queue again.
mq_unlink just deletes the file while mq_close frees the resources of the mqd_t
struct.
Manuel
> -Original Message-
> Sent: Monday, April 04, 2011 2:50 PM
> Subject:
When I type ahead in an uncustomized terminal window, I expect my
keyboard input to be queued until it is called for. When I press
Ctrl+C, I expect the queue to be flushed. Any keyboard input still
in the queue should be lost.
The trouble I am having is that my keyboard input is preserved when
I p
On 4/4/2011 12:39 AM, Andy Koppe wrote:
On 4 April 2011 06:44, Daniel Colascione wrote:
Attached is a small program that runs a set of processes under an NT job
object, allowing you to stop, resume, and kill them using normal Cygwin
job control --- whether or not these processes are Cygwin progr
Attached is a small program that behaves very similarly to ln(1), but
that works with Windows hard and symbolic links instead of Cygwin ones.
Successful use of this program requires Vista or newer, a user with
SeCreateSymbolicLinkPrivilege, and a symlink evaluation policy that
allows the kind
On Fri, Apr 01, 2011 at 01:25:47AM -0400, Christopher Faylor wrote:
>Since it's in the dll_init() function, I don't see how it could be pipe
>related.
I could duplicate the problem on Windows 7 (64-bit) but it went away
once I rebased.
Have people tried that?
Even if that "fixes" the problem, t
On Mon, Apr 4, 2011 at 11:17 PM, Christopher Faylor wrote:
> On Fri, Apr 01, 2011 at 01:25:47AM -0400, Christopher Faylor wrote:
>>Since it's in the dll_init() function, I don't see how it could be pipe
>>related.
>
> I could duplicate the problem on Windows 7 (64-bit) but it went away
> once I r
I'm getting weird behavior from grep. Searching for a bracketed range of
characters (i.e. [A-Z]) is doing case-insensitive matching, while an identical
but explicit character set match (i.e. [ABCDE...Z]) does not. Examples below.
Output of "cygcheck -s -v -r" attached.
LANG=en_US
GREP_OPTION
On 04/04/2011 04:09 PM, Jim Garrison wrote:
> I'm getting weird behavior from grep. Searching for a bracketed range of
> characters (i.e. [A-Z]) is doing case-insensitive matching, while an
> identical but explicit character set match (i.e. [ABCDE...Z]) does not.
Your problem is not with grep, b
Dear CygWin users / developers!
While trying to link statically my application against GraphicsMagick
under CygWin, but I suffer from few minor problems during linking.
To discover the library list, needed for static linking, I use
"GraphicsMagick++-config --libs":
> configure:7259: g++ -o conft
2011/4/5 Dmitry Katsubo
> Dear CygWin users / developers!
>
> While trying to link statically my application against GraphicsMagick
why not dynamic ?
> under CygWin, but I suffer from few minor problems during linking.
>
> To discover the library list, needed for static linking, I use
> "Graphics
Hi,
The development group that I work in has been experiencing random
failures when starting programs from Cygwin. The problem only occurs
when McAfee's (version 8.7i) on-access scanner McShield is running. We
do not have official control over this, so disabling it is not an
option.
I have tried
On Mon, Apr 04, 2011 at 08:34:38PM -0400, Jonathan Pearson wrote:
>Hi,
>
>The development group that I work in has been experiencing random
>failures when starting programs from Cygwin. The problem only occurs
>when McAfee's (version 8.7i) on-access scanner McShield is running. We
>do not have offi
20 matches
Mail list logo
