On 7/26/2013 10:10 AM, Corinna Vinschen wrote:
> On Jul 26 09:55, Daniel Colascione wrote:
>> On 7/26/2013 9:35 AM, Corinna Vinschen wrote:
>>> On Jul 26 09:21, Daniel Colascione wrote:
>>>> On 7/26/2013 8:27 AM, Christopher Faylor wrote:
>>>>> On
On 7/26/2013 9:35 AM, Corinna Vinschen wrote:
> On Jul 26 09:21, Daniel Colascione wrote:
>> On 7/26/2013 8:27 AM, Christopher Faylor wrote:
>>> On Thu, Jul 25, 2013 at 11:44:32PM -0700, Daniel Colascione wrote:
>>>
>>>> Ugly, only half-implemented,
On 7/26/2013 8:27 AM, Christopher Faylor wrote:
> On Thu, Jul 25, 2013 at 11:44:32PM -0700, Daniel Colascione wrote:
>
>> Ugly, only half-implemented, but better: a hook-based pseudoconsole
>> system for Windows.
>
> This is what I was holding out for. The last time i
On 7/25/2013 11:13 PM, Christopher Faylor wrote:
> It has been suggested here a couple of times that it might be a good
> idea for Cygwin to fill out the block that it sends to subprocesses with
> information that fools msvcrt programs into thinking that its ptys are
> really consoles.
My suggesti
On 7/25/2013 12:11 AM, Daniel Colascione wrote:
> On 7/24/2013 11:55 PM, Daniel Colascione wrote:
>> Does that help at all? I only started seeing this problem after I recompiled
>> _wp.dll using gcc 4.7.3.
>
> Actually, this problem looks a lot like
> http://www.mail-arc
On 7/24/2013 11:55 PM, Daniel Colascione wrote:
> Does that help at all? I only started seeing this problem after I recompiled
> _wp.dll using gcc 4.7.3.
Actually, this problem looks a lot like
http://www.mail-archive.com/gcc@gcc.gnu.org/msg68316.html: neither Python nor
_wp links dynamica
I just started seeing this problem myself --- on 1.7.22 release.
On 5/22/2013 5:31 AM, Corinna Vinschen wrote:
> On May 22 11:11, Denis Excoffier wrote:
>> Hello,
>>
>> With the current snapshot (20130521) on Windows XP, the following
>> fails (with an empty stackdump):
>>
>> % /usr/bin/python pyf
On 6/12/2013 11:44 AM, Christopher Faylor wrote:
> On Wed, Jun 12, 2013 at 11:06:15AM -0700, Daniel Colascione wrote:
>> On 6/12/2013 2:46 AM, Corinna Vinschen wrote:
>>> On Jun 11 17:53, Daniel Colascione wrote:
>>>> g++ -L/users/dancol/software/cygwin/i686-pc
On 6/12/2013 2:46 AM, Corinna Vinschen wrote:
> On Jun 11 17:53, Daniel Colascione wrote:
>> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
>> /users/dancol/software/cygwin/winsup/cygwin/include
>> -B/users/dancol/software/cygwin/i686-pc-cygwin/newli
g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem
/users/dancol/software/cygwin/winsup/cygwin/include
-B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem
/users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem
/users/dancol/software/cygwin/newli
On 6/10/2013 12:21 PM, Warren Young wrote:
> On 6/9/2013 19:26, Daniel Colascione wrote:
>> which I haven't been able to test
>
> You should. One of the changes is to prefer creating temporary tables in
> memory
> instead of on disk, which should bypass the prob
The mandatory locking work (which I haven't been able to test) aside, temporary
table creation is broken with SQLite 3.7.16.2-1. 'CREATE TEMP TABLE foo (bar
INT)' fails. cygwinGetTempname, called from getTempname, returns the correct
temporary directory --- "/var/tmp/etilqs_z28HceqmzVr3ZO1" in my c
On 6/7/2013 11:55 PM, Daniel Colascione wrote:
> (By the way: how on earth does logon eventually succeed if group enumeration
> fails? I'm using the stored-password authentication method, and when sshd
> eventually connects, my user (according to whoami.exe /priv) is a member of
&g
In sec_auth.cc, get_server_groups contains this clause:
if (get_logon_server (domain, server, false)
&& !get_user_groups (server, grp_list, user, domain)
&& get_logon_server (domain, server, true))
get_user_groups (server, grp_list, user, domain);
The first call to get_logon_ser
On 4/3/2013 1:01 AM, Thomas Wolff wrote:
> Am 03.04.2013 09:15, schrieb Daniel Colascione:
>> In light of the recent discussion on the developers list about native
>> symlinks,
>> I'd like to suggest including my winln program (which I posted a while ago on
>> th
On 4/3/2013 12:15 AM, Daniel Colascione wrote:
> In light of the recent discussion on the developers list about native
> symlinks,
> I'd like to suggest including my winln program (which I posted a while ago on
> this list, and which I've attached to this message) in the cy
#include
#define PRGNAME "winln"
#define PRGVER "1.2"
#define PRGAUTHOR "Daniel Colascione "
#define PRGCOPY "Copyright (C) 2011 " PRGAUTHOR
#define PRGLICENSE "GPLv2 or later <http://www.gnu.org/licenses/gpl-2.0.html>"
stat
On 3/13/2013 8:44 AM, Ryan Johnson wrote:
> On 13/03/2013 11:33 AM, Filipp Gunbin wrote:
>> On 13/03/2013 18:53 +0400, Achim Gratz wrote:
>>
>>> Filipp Gunbin fastmail.fm> writes:
"Two new functions are available in Cygwin builds:
`cygwin-convert-file-name-from-windows' and
`cygwin-
On 3/9/2013 9:50 PM, Arthur Tu wrote:
> On 3/9/2013 9:23 PM, Ken Brown wrote:
>> On 3/8/2013 10:08 PM, Arthur Tu wrote:
>>> Hope this can be fixed soon.
>>
>> It looks like the problem has been fixed. I've built a new version of emacs
>> with the fix included and put it in my private cygwin reposi
On 3/4/2013 1:39 PM, Corinna Vinschen wrote:
> On Mar 4 16:26, Ken Brown wrote:
>> On 3/4/2013 11:24 AM, Arthur Tu wrote:
>>> Today when i tried to drag a file whose name containing chinese
>>> characters into emacs, it failed to open.
>>>
>>> Here is the brief review:
>>>
>>> 1. a file with a pur
On 2/12/2013 12:31 PM, Ken Brown wrote:
> On 2/12/2013 12:30 PM, Arthur Tu wrote:
>> 1. Emacs-w32 depends on several libraries, such as libXpm-noX_4.
>> However, these dependencies haven't been solved by setup.exe.
>
> libXpm-noX_4 is listed in setup.ini as a dependency of emacs-w32. I don't
> k
On 2/3/2013 4:40 AM, Ken Brown wrote:
> On 2/3/2013 6:05 AM, Андрей Забавников wrote:
>> $ emacs-w32 --daemon
>> emacs daemon: exec failed: 2
>> Error: server did not start correctly
>
> I can confirm this. Daniel, can you help?
=== modified file 'src/emacs.c'
--- src/emacs.c 2013-02-02 17:14:24
On 1/2/13 12:48 PM, Christopher Faylor wrote:
> I managed to duplicate a hang by really stressing ctrl-c a loop. It
> uncovers some rather amazing Windows behavior which I have to think
> about. Apparently ExitThread can be called recursively within the
> thread that Windows creates to handle CTR
On 12/21/2012 11:36 AM, Christopher Faylor wrote:
> On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>> On Dec 21 11:10, Christopher Faylor wrote:
>>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
Maybe the signal thread should really not exit by itself, bu
On 12/6/12 7:13 PM, Ken Brown wrote:> And I've just discovered what
that something is: After the cygw32
> build is configured, HAVE_GSETTINGS and HAVE_GCONF are defined to be 1
> in src/config.h (assuming you have the relevant -devel packages
> installed). And GSettings and GConf are Glib feature
On 12/6/12 1:51 PM, Achim Gratz wrote:
> Daniel Colascione writes:
>>>> Open another mintty and try to kill the hanging emacs process from it.
>>
>> Works fine for me, albeit using kill -9, not regular kill. What
>> exactly do you see?
>
> The kill command
On 12/6/12 1:54 PM, Achim Gratz wrote:
> Daniel Colascione writes:
>> Under Cygwin, the variable system-type will be 'cygwin; under Windows,
>> it will be 'windows-nt. You can perform conditional initialization as
>> follows:
>>
>> (cond ((eq system-ty
On 12/6/12 1:37 PM, Achim Gratz wrote:
> Yes, either that or via site-init.el. Currently when it reads in the
> customization it finds a default font that doesn't make any sense in
> Win32 and it ends up using Arial (probably because its the first on the
> list, so it seems it doesn't even bother
Thanks for highlighting the issue.
On 12/6/12 1:00 PM, Ken Brown wrote:
> On 12/6/2012 1:47 PM, Achim Gratz wrote:
>> Ken Brown writes:
>>> emacs-w32 shouldn't require dbus-daemon, as far as I know. This
>>> sounds like a bug. Could you give me a specific recipe for
>>> reproducing the problem?
On 12/5/2012 11:39 AM, Andrey Repin wrote:
> it does not make a difference between "/"
> and "\" on the very low level
Yes it does. NT itself cares very much what kind of slash you use. It's the
Win32 layer that does the translation.
> Anyone know a filesystem or operating system, which is using
Since upgrading to Cygwin 1.7.17, I've seen Emacs occasionally print "select
error: no error", indicating that select returned -1 while leaving errno set to
zero. I haven't come up with a repro or simple testcase yet, but I figured I'd
make someone aware of the problem.
signature.asc
Description
On 8/16/2012 12:41 AM, Achim Gratz wrote:
> $ sqlite3
> SQLite version 3.7.13 2012-06-11 02:05:22
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> CREATE TEMP TABLE two (id INTEGER NOT NULL, name CHAR(64) NOT NULL );
> Error: unable to open database file
> sql
On 10/17/2012 4:58 PM, Andrey Repin wrote:
> Greetings, Gary Oberbrunner!
>
>> I understand about not installing cygwin in c:\. But I really want a single
>> filesystem, so cygwin's / is Windows c:/, and cygwin /Program\ Files is
>> Windows /Program Files and so on.
>
> Having single filesystem,
GNU Emacs 24.3, due out in about a month, will have a new
configuration option: --with-w32. When built this way, Cygwin Emacs
uses native Win32 widgets instead of X11. The resulting "cygw32" Emacs
looks just like NT Emacs, but is a native Cygwin application with full
support for Cygwin paths, ptys
On 9/17/12 6:48 AM, Christopher Faylor wrote:
> On Mon, Sep 17, 2012 at 03:42:14PM +0200, V??clav Zeman wrote:
>> On 17 September 2012 15:27, Charles Wilson wrote:
>>> Well, that's exactly what Console2 does, and it works pretty well.
>>> I've never seen any "missing" data when using it. I don't k
On 9/15/2012 9:21 AM, Christopher Faylor wrote:
> On Sat, Sep 15, 2012 at 12:15:49PM -0400, Earnie Boyd wrote:
>> I just discovered https://github.com/rprichard/winpty and thought
>> Cygwin users and developers may be interested. The license is MIT
>> style.
>
> Looks interesting. I've had somet
On 9/13/2012 12:57 PM, Andy Koppe wrote:
> mintty 1.1.2-1 is on its way to the Cygwin mirrors.
>
> CHANGES
> ===
> - Fixed buffer overflow in processing of the control sequence for
> querying font coverage.
> - Tweaked double-click word selection algorithm to handle shell
> variable references
On 9/7/12 1:17 PM, Fausto Arinos Barbuto wrote:
>> You need *a* firewall and *an* antivirus, but not necessarily *those*
>> specific products. If you're serious about using Cygwin, you'll
> want to
>> find alternatives that aren't BLODA.
>
> You are right on spot as for that, but unfortunately Zo
On 8/27/2012 11:26 PM, thoni56 wrote:
> Is this a known behaviour? Unavoidable in cygwin? (Obviously not, if I'm on
> the right track with my guesswork...) If it is a bug, will it be fixed?
This behavior isn't Cygwin-specific. In fact, it's longstanding Unix behavior.
(The buffering problem is one
On 8/22/12 12:10 PM, David Sastre Medina wrote:
> On Tue, Aug 21, 2012 at 10:16:28AM +, Achim Gratz wrote:
>> I'm removing the Windows PATH in my startup scripts since there's nothing in
>> there that I think should be accessible from Cygwin.
>> For (t)csh this is easy enough to do with droppin
On 8/17/2012 5:45 PM, Daniel Brown wrote:
> for(i=0;i<10;i++)
> printf("%d\n", b[i]);
^^
You want %g or %f.
signature.asc
Description: OpenPGP digital signature
On 8/16/2012 8:51 PM, Daniel Colascione wrote:
> On 8/16/2012 11:43 AM, Christopher Faylor wrote:
>> On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
>>> When run on a Linux machine, this program starts up and blocks on
>>> sigwaitinfo.
>>> Yo
On 8/16/2012 11:43 AM, Christopher Faylor wrote:
> On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
>> When run on a Linux machine, this program starts up and blocks on
>> sigwaitinfo.
>> You can suspend and resume the program using usual job control faci
When run on a Linux machine, this program starts up and blocks on sigwaitinfo.
You can suspend and resume the program using usual job control facilities, and
on SIGINT, the program prints a message and exits. When the program resumes
after being stopped, it prints "resumed".
With the 2012-08-07 Cy
On 8/13/12 11:56 AM, Christopher Faylor wrote:
> On Mon, Aug 13, 2012 at 07:56:52PM +0200, Pawel Jasinski wrote:
>> hi guys,
>>
>> is that what we talking about (see patch below)?
>
> Thanks for the patch but I wasn't looking for a simple patch to do this.
> I said I'd make the change if someone c
On 8/9/12 8:29 PM, Zach Saw wrote:
> Corinna Vinschen cygwin.com> writes:
>
>> Thanks for the testcase, but... would you mind to change it to take the
>> boost lib out of the picture, by using just plain pthread functions, if
>> possible in plain C?
>
> Apparently someone else has already encoun
On 8/9/12 2:21 AM, Achim Gratz wrote:
> Christopher Faylor cygwin.com> writes:
>> You mention generic "signal handling" rather than "sigwaitinfo" so I don't
>> know if there are other issues. It doesn't seem like much would work if
>> signal handling was completely broken, though.
>
> With the l
On 8/8/2012 2:59 PM, Christopher Faylor wrote:
> On Mon, Aug 06, 2012 at 05:15:10PM -0700, Daniel Colascione wrote:
>> On 8/6/2012 2:07 PM, Daniel Colascione wrote:
>>> I just saw a hang building Emacs (using "make bootstrap")
>>
>> Signal handling appear
On 8/6/2012 5:15 PM, Daniel Colascione wrote:
> On 8/6/2012 2:07 PM, Daniel Colascione wrote:
>> I just saw a hang building Emacs (using "make bootstrap")
>
> Signal handling appears to be broken. Here's a simple testcase. Run the
> program
> and hit con
On 8/6/2012 2:07 PM, Daniel Colascione wrote:
> I just saw a hang building Emacs (using "make bootstrap")
Signal handling appears to be broken. Here's a simple testcase. Run the program
and hit control-c. It'll print "got Alarm clock", then stop accepting any
On 8/6/2012 7:37 AM, Filipp Gunbin wrote:
> Christopher Faylor writes:
>
>> We're considering rolling a new release which fixes some of the problems
>> which have cropped up here in the last few weeks.
>>
>> So, if you haven't already, we'd appreciate having people try out the
>> latest snapshot a
On 8/5/12 8:34 PM, Christopher Faylor wrote:
> We're considering rolling a new release which fixes some of the problems
> which have cropped up here in the last few weeks.
>
> So, if you haven't already, we'd appreciate having people try out the
> latest snapshot at: http://cygwin.com/snapshots/ .
On 8/3/2012 3:33 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> Hi All,
>
> I have a native Windows app that is run from bash (which is in turn run
> in a standard Cygwin terminal window, mintty). The application's code uses
> kbhit() to check whether input is available from the user -- but it
On 8/2/2012 4:00 PM, Christopher Faylor wrote:
> On Thu, Aug 02, 2012 at 09:32:09PM +0200, Marcin Kielar wrote:
>> Steps to reproduce:
>>
>> 1. Start cygwin using cygwin.bat
>> 2. Run `ping -t google.com`
>> 3. Try breaking it with Ctrl+C
>>
>> Expected behaviur:
>> The ping breaks execution and th
On 8/2/2012 2:02 PM, Roger K. Wells wrote:
> On 08/02/2012 04:26 PM, Daniel Colascione wrote:
>> On 8/2/2012 12:32 PM, Marcin Kielar wrote:
>>> Steps to reproduce:
>>>
>>> 1. Start cygwin using cygwin.bat
>>> 2. Run `ping -t google.com`
>>>
On 8/2/2012 12:32 PM, Marcin Kielar wrote:
> Steps to reproduce:
>
> 1. Start cygwin using cygwin.bat
> 2. Run `ping -t google.com`
> 3. Try breaking it with Ctrl+C
This problem arises from Cygwin's use of CREATE_NEW_PROCESS_GROUP. From MSDN:
"When a process is created with CREATE_NEW_PROCESS_GR
On 7/26/2012 8:03 PM, Yaakov (Cygwin/X) wrote:
> On 2012-07-26 16:46, Daniel Colascione wrote:
>> $ g++ -std=gnu++0x foo.cpp
>> /tmp/ccS3vCW7.o:foo.cpp:(.text$_ZNSt11basic_regexIcSt12regex_traitsIcEEC1EPKcj[std::basic_regex>
>> std::regex_traits >::basic_regex(char con
/tmp
$ cat foo.cpp
#include
#include
int
main()
{
std::regex e("hello");
}
$ g++ -std=gnu++0x foo.cpp
/tmp/ccS3vCW7.o:foo.cpp:(.text$_ZNSt11basic_regexIcSt12regex_traitsIcEEC1EPKcj[std::basic_regex >::basic_regex(char const*, unsigned
int)]+0x60): undefined reference to `std::basic_regex >:
On 7/26/12 9:34 AM, Adam Dinwoodie wrote:
> Daniel Colascione wrote:
>> I still don't know why anyone wouldn't want to use pipe_byte all the time.
>
> I think that was covered pretty explicitly by cgf in reply to you some time
> ago:
Cygwin still uses message pipes fo
On 7/26/12 7:47 AM, Noel Grandin wrote:
> I'm running into the pipe_byte problem while trying to use
> Visual-Studio's C compiler from inside cygwin.
> I'm running latest cygwin (from a few days ago).
>
> Specifically, I'm building LibreOffice on a 64-bit Windows7 box.
>
> Is there any way to tri
On 7/13/12 9:30 AM, Reini Urban wrote:
> On Fri, Jul 13, 2012 at 9:26 AM, Corinna Vinschen wrote:
>> On Jul 13 07:52, Reini Urban wrote:
>>> On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote:
>>>> On Jul 12 20:48, Daniel Colascione wrote:
>>>>>
On 7/13/12 10:26 AM, Christopher Faylor wrote:
> So, everyone, please let this drop unless you have a constructive
> suggestion.
Speaking of pragmatism: what about a CYGWIN environment variable to
turn off the behavior? That way, people like the OP could extract
their archives without worry, and i
On 7/10/12 8:41 AM, Daniel Colascione wrote:
> On 7/10/12 1:13 AM, Corinna Vinschen wrote:
>> On Jul 9 21:59, Daniel Colascione wrote:
>>> On 7/9/12 2:26 PM, Daniel Colascione wrote:
>>>> [snip]
>>>
>>> It turns out that clisp crashes only when I&
On 7/10/12 1:13 AM, Corinna Vinschen wrote:
> On Jul 9 21:59, Daniel Colascione wrote:
>> On 7/9/12 2:26 PM, Daniel Colascione wrote:
>>> [snip]
>>
>> It turns out that clisp crashes only when I've rebased DLLs into the
>> high portion of the 4GB WOW64
On 7/9/12 2:26 PM, Daniel Colascione wrote:
> [snip]
It turns out that clisp crashes only when I've rebased DLLs into the
high portion of the 4GB WOW64 address space. It looks like clisp isn't
32-bit clean. Turning off bigaddr on lisp.exe lets clisp load, but of
course
On 7/9/12 2:01 PM, Reini Urban wrote:
> On Sat, Jul 7, 2012 at 2:07 PM, Daniel Colascione wrote:
>> On 7/7/2012 10:44 AM, marco atzeri wrote:
>>> On 7/7/2012 6:19 PM, Reini Urban wrote:
>>>> On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote:
>>>&
On 7/7/2012 10:44 AM, marco atzeri wrote:
> On 7/7/2012 6:19 PM, Reini Urban wrote:
>> On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote:
>>> On 7/7/12 6:04 AM, marco atzeri wrote:
>>>> On 7/7/2012 12:45 AM, Daniel Colascione wrote:
>>>>> $ c
On 7/7/2012 9:51 AM, Andrey Repin wrote:
>>> your mount table looks strange
>>>
>>> C:/ system binary,auto
>>> c:\bin/binsystem text,cygexec
>>> c:/bin/usr/binsystem text,cygexec
>>> C:\lib/usr/libsyste
On 7/7/12 6:04 AM, marco atzeri wrote:
> On 7/7/2012 12:45 AM, Daniel Colascione wrote:
>> $ clisp
>
> Trimming a bit ?
Not at all. I just installed the stock clisp package and tried to run it.
> your mount table looks strange
>
> C:/ syst
On 6/28/12 12:34 PM, ping wrote:
> I still miss the magic sshfs tool
> in linux...
You can make it happen. In principle, FUSE should work as well in
Cygwin as it does under Linux, albeit for Cygwin programs only. It'd
just be a matter of writing the glue logic and hooking into Cygwin's
VFS interna
On 5/26/12 4:40 PM, Linda Walsh wrote:
>
> Compiling for 64-bit is about memory alignment and native instruction
> set/word size execution. The alignment will likely cause runtime
> memory usage
> to grow somewhat, but it shouldn't be significant in most case
So the x32 ABI [1] should be bet
On 5/14/12 11:12 AM, Ken Jackson wrote:
> Mon, May 14, 2012 at 01:46PM -0400 LMH wrote:
>> As an aside, I've wondered for some time why this group is a mailing
>> list and not a vBulletin type forum.
>
> I second the motion.
>
No.
Mailing lists are infinitely easier to filter, archive, and
On 5/9/12 1:11 PM, Christopher Faylor wrote:
> Please stop thinking that there is a simple solution that you can
> intuit without fully understanding how Cygwin works.
Indeed. _Everything_ is more complicated than it looks.
>
> 1.7.15 will contain a new CYGWIN option "pipe_byte" which will force
On 5/6/12 11:16 AM, Andrew DeFaria wrote:
>> Yes. Just use mintty. It's the default and it works.
> I use mintty and Console. One good thing about Console it understands
> pty's or does something in the face of pty's that cause it to work in
> certain circumstances that mintty fails in. My example
On 5/6/12 1:09 PM, Christopher Faylor wrote:
> [cmd /c start foo not going into the background]
> It is not likely to change.
What worries me isn't that the behavior changed, but that the new
behavior is weird. SIGINT doesn't work on processes spawned by cmd /c
start.
Try it yourself:
$ cmd /c s
On 5/6/12 12:29 PM, Andy Koppe wrote:
> mintty 1.1.0-1 (aka 1.1-beta1) is on its way to the Cygwin mirrors.
> This is a test release.
Can you please consider applying my patch to mintty's exit behavior at
https://code.google.com/p/mintty/issues/detail?id=319 ? This patch
makes mintty's behavior co
On 4/27/12 10:27 PM, Christopher Faylor wrote:
> The above comment shows an "and" relationship here. Message type pipes
> more closely mimic Linux (UNIX) pipe behavior AND are definitely
> required for ptys.
Yeah, but because message pipes break other programs. Cygwin has only
been using message
On 4/27/2012 3:38 PM, James Johnston wrote:
> So I think for sure, Cygwin's use of message pipes is breaking a lot
> of Windows software, because of the null writes. And ALSO additionally
> perhaps because of this: while reading MSDN today, I came across an
> interesting snippet that probably indic
On 2/6/12 8:35 PM, jojelino wrote:
> 2012-02-06 AM 1:29, Corinna Vinschen 쓴 글:
>> Hi Cygwin friends and users,
>>
>
> C:\Documents and Settings\Administrator>base64 oso|base64 -d -
> base64: write error: Bad file descriptor
> base64: write error
>
> C:\Documents and Settings\Administrator>uname -
On 1/17/12 1:32 AM, Pan ruochen wrote:
> Hi Al,
>
> Cygwin treat most of files executive. But I really don't like this
> feature. Is there any option to disable it?
>
Here excerpts from my configuration files. I can't change the
executable permission issue, but I can tweak my environment so that
On 1/11/12 10:22 PM, Paul Allen Newell wrote:
> On 1/11/2012 7:37 PM, Gary Johnson wrote:
>>
>> mintty -e tail -f foo&
>>
>> The -e is optional, but I like keeping my mintty commands consistent
>> with those I write for other terminals.
>>
>> HTH,
>> Gary
>>
> I am using cygwin 1.7.9-1 per cyg
On 1/11/12 7:07 PM, Jon Hughes wrote:
> What I want to do is open a new cygwin window
There's no such thing as a "cygwin window". Do you mean a mintty instance?
> with a tail command, so
> I have the parent process still running, and this runoff process in
> another window. I've found cygstart,
On 1/9/12 11:22 PM, Henry S. Thompson wrote:
> Corinna Vinschen writes:
>
>> it's nice to know that you could increase the performance by increasing
>> the buffer sizes. However, I'm reluctant to implement this as a generic
>> option. As far as I know the socket buffers are taken from nonpaged p
On 1/7/12 12:49 PM, inetjunkmail wrote:
> First a quick aside to say thank you for Cygwin Terminal. I can't
> articulate how nice it is to be freed of cmd.exe!
You were always free of cmd.exe, which is akin to bash. Now you're
also free of conhost, the closest thing windows has to a terminal
emul
On 1/3/2012 4:20 PM, Christopher Faylor wrote:
>> but it sounds interesting (especially if it allows less-frequent
>> invocation of the rebaseall ritual).
>
> Since the VAST majority of UNIX/linux programs use fork/exec I don't
> see how this would really have much of an effect.
The idea is to ad
> However, you should check out the copyright assignment requirements [2]
> if you want the code to make it upstream.
Of course I'll assign copyright if the code makes it upstream in some form.
Thanks,
Daniel Colascione
--
Problem reports: http://cygwin.com/problems.html
FAQ:
ine PRGVER "1.3"
#define PRGAUTHOR "Daniel Colascione "
#define PRGCOPY "Copyright (C) 2011 " PRGAUTHOR
#define PRGLICENSE "GPLv2 or later <http://www.gnu.org/licenses/gpl-2.0.html>"
#ifndef PROCESS_QUERY_LIMITED_INFORMATION
#define PROCESS
IN32_WINNT 0x0500 /*Win2k*/
#define STRICT
#define UNICODE 1
#define _UNICODE 1
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PRGNAME "winln"
#define PRGVER "1.1"
#define PRGAUTHOR "Daniel Cola
With the latest cygwin1.dll snapshot, the existing cygrunsrv binary
(version 1.34-1, the latest version from setup.exe) segfaults on
startup, sending a message to the Windows Application log or syslog,
depending on whether syslog is running. This segfault happens only when
I try to run the service
Currently, cygrunsrv --help dumps output to standard error. This
behavior is a slight annoyance because it results in cygrunsrv --help |
less not being very helpful. Can cygrunsrv --help dump its output to
stdout instead?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 6/6/2011 9:01 AM, Andrew Schulman wrote:
> Am I right that bzr is just completely broken in Cygwin? If so, is there
> an ETA to get it fixed?
>
> My bzr is 2.3.1-1, in Cygwin 1.7.9. No matter what bzr command I run, I
> always get the same result:
As a quick workaround, you can delete all th
On 7/30/11 2:09 PM, Christopher Faylor wrote:
> I've checked in a change which uses QueueUserAPC to create threads like
> the signal thread. As everyone has noted this seems to have a salutory
> effect on the OP's test case.
>
> I don't entirely understand why the code which already existed in Cy
On 7/28/11 12:24 PM, Larry Hall (Cygwin) wrote:
> On 7/28/2011 3:01 PM, Ed wrote:
>>
>> Quite often when I open a Cygwin session when it runs a .bashrc script it
>> will show errors of basic commands not found. For example pwd or ls returns
>> command not found when I type it at the command pr
On 6/26/11 11:37 AM, Andy wrote:
> I achieved the desired effect of modifying the nonvirtualized _vimrc by
> clicking
> on Compatibility Files to go to the virtualization directory and moving it
> from
> there to the location ov the nonvirtualized _vimrc (thus overwriting it).
I usually run with
On 5/30/11 10:46 AM, Christopher Faylor wrote:
> On Mon, May 30, 2011 at 07:34:27AM +, Juanjo wrote:
>> Christopher Faylor writes:
>>> Unfortunately, cygwin_attach_handle_to_fd doesn't really work. Cygwin
>>> needs to know the type of handle it is attaching in order to set up the
>>> correct t
On 4/24/11 9:39 AM, Christian Franke wrote:
> On 2011-04-01, Christian Franke wrote:
>> The attached patch for /etc/profile and /etc/bash.bashrc sets a root
>> prompt ('#' instead of '$' or '%') if the shell runs with admin rights
>> (local or domain admin group).
>>
>
> Any comment so far? Wrong
On 4/6/2011 1:26 AM, Andy Koppe wrote:
On 4 April 2011 21:30, Daniel Colascione wrote:
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
an be used via a simple shell alias (or
PATH prefixing, if you're feeling bold).
#define _WIN32_WINNT 0x0500 /*Win2k*/
#define STRICT
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define PRGNAME "winln"
#define PRGVER "1.0&q
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
efine PRGNAME "injob"
#define PRGVER "1.0"
#define PRGAUTHOR "Daniel Colascione "
#define PRGCOPY "Copyright (C) 2011 " PRGAUTHOR
#define PRGLICENSE "GPLv2 or later <http://www.gnu.org/licenses/gpl-2.0.html>"
/**
* Small utility to run an arbitrary
1 - 100 of 156 matches
Mail list logo
