On Tue, Sep 20, 2022 at 06:18:54PM -0700, Ken Brown wrote:
>
> On 9/20/2022 2:54 AM, Enrico Forestieri wrote:
> >
> > I compared the behavior of read() and select() on 3 different platforms.
> > My conclusion is that, actually, read() behaves the same on all of t
On Mon, Sep 19, 2022 at 07:54:11PM -0400, Ken Brown wrote:
>
> On 9/19/2022 6:05 PM, Enrico Forestieri wrote:
> > Ken Brown wrote:
> > >
> > > I did an internet search on this issue and found the following, which
> > > describes the
> > >
>
Ken Brown wrote:
> I did an internet search on this issue and found the following, which
describes the
> situation we're discussing:
https://stackoverflow.com/questions/14594508/fifo-pipe-is-always-readable-in-select
> According to that post, select on Linux will wait for a writer the
Hi,
I think I am experiencing a problem with fifos on cygwin. The attached
C source (fifocomm.c) creates two pipes (/tmp/pipe.{in,out}), expecting
to receive inputs from /tmp/pipe.in and replying to /tmp/pipe.out.
Compiling this source on linux and launching it produces on the terminal
1)
On Sat, Jan 30, 2021 at 02:53:29PM -0500, Chris Marshall wrote:
> Hi,
>
> Yesterday I started some documentation work using my favorite LyX cygwin
> install:
>
> > CYGWIN_NT-10.0 mypc 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin
>
> and
>
> > lyx --version
> > LyX 2.3.5-1 (2020-06-02)
> >
On Mon, Jun 08, 2020 at 07:24:19PM +0200, Thomas Wolff wrote:
> I have uploaded mintty 3.1.8 with the following changes:
>
> Terminal features
> * Handle new lines within OSC strings, ignore for image data (#1010).
>
> Keyboard handling
> * Optional legacy Alt modifier fallback for AltGr
On Sun, Jun 07, 2020 at 04:42:03PM +0200, Thomas Wolff wrote:
> Am 07.06.2020 um 15:07 schrieb Enrico Forestieri:
> > On Sun, Jun 07, 2020 at 02:55:25PM +0200, Thomas Wolff wrote:
> > > Am 07.06.2020 um 13:50 schrieb Enrico Forestieri:
> > > > According to
> >
On Sun, Jun 07, 2020 at 02:55:25PM +0200, Thomas Wolff wrote:
> Am 07.06.2020 um 13:50 schrieb Enrico Forestieri:
> > According to
> > https://github.com/mintty/mintty/wiki/Keycodes#altgr
> > when the keyboard layout does not have a keycode for an AltGr
> > combinatio
According to
https://github.com/mintty/mintty/wiki/Keycodes#altgr
when the keyboard layout does not have a keycode for an AltGr
combination, the AltGr key is treated as Alt instead.
I have the following entry in ~/.inputrc
"\e'": "`" # Alt+' -> `
and, as AltGr+' is not a
On Wed, 03 Jun 2020 at 11:03:27PM +0200, Ken Brown wrote:
> There were some major changes in Cygwin's fifo implementation in
cygwin 3.1.0.
> It doesn't seem to have gotten a lot of testing until fairly recently,
when some
> bugs were discovered and fixed in cygwin 3.1.5. Have you tried the
On Mon, Jun 01, 2020 at 10:26:05PM +0200, Marco Atzeri wrote:
> On 29.05.2020 17:29, Enrico Forestieri wrote:
> > On Thu, May 28, 2020 at 10:01:15PM +0200, Marco Atzeri via Cygwin wrote:
> >> On 28.05.2020 20:25, Enrico Forestieri wrote:
> >>> On Thu, May 28, 2020 at
On Thu, May 28, 2020 at 10:01:15PM +0200, Marco Atzeri via Cygwin wrote:
> On 28.05.2020 20:25, Enrico Forestieri wrote:
> > On Thu, May 28, 2020 at 08:09:49PM +0200, Marco Atzeri via Cygwin wrote:
> > >
> > > after installing also another package
> > > texliv
On Thu, May 28, 2020 at 08:09:49PM +0200, Marco Atzeri via Cygwin wrote:
>
> after installing also another package
> texlive-collection-pstricks
>
> I was able to have an instant preview
>
> can you check if the test 2.3.4.2-2
> solve the issue also for you ?
> Than I can promote it to stable
On Thu, May 28, 2020 at 07:35:12PM +0200, Marco Atzeri via Cygwin wrote:
> On 28.05.2020 12:50, Enrico Forestieri wrote:
> > Hi,
> >
> > when activating instant preview in Tools>Preferences>Display, one can
> > preview a latex snippet in the lyx work area by in
Hi,
when activating instant preview in Tools>Preferences>Display, one can
preview a latex snippet in the lyx work area by inserting it in a
preview inset (Insert>Preview).
However, since version 3.1.0 it does not work anymore, in the sense
that the preview is not generated. As this feature is
On Mon, Feb 18, 2019 at 09:54:50PM +0100, Corinna Vinschen wrote:
> On Feb 18 17:04, Enrico Forestieri wrote:
> > On Mon, Feb 18, 2019@03:11:11PM +0100, Corinna Vinschen wrote:
> > >
> > > Two workarounds for now:
> > >
> > > - Start sshd as
On Mon, Feb 18, 2019 at 03:11:11PM +0100, Corinna Vinschen wrote:
>
> Two workarounds for now:
>
> - Start sshd as 64 bit Cygwin process.
> - Utilize https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd3
Thank you. The second method above worked. This is a private network,
so that is Ok.
After upgrading to cygwin 3.0.0 (32bit version) on W7 64bit, it is
not possible to connect using ssh. The returned error is something
like "Connection closed by x.x.x.x port 22".
I also tried the 2019-02-18 snapshot without success.
However, simply downgrading to 2.11.2 fixes the issue.
This
Yaakov writes:
The following packages (and their subpackages) have been updated for
both arches:
[...]
* gamin-0.1.10-14
After this update, all programs using libfam crash.
For example, the test program that can be also found here:
http://www.fifi.org/doc/libfam-dev/examples/test.c++.gz
It
Corinna Vinschen wrote:
Hi Cygwin friends and users,
I just released 1.7.15. This is a bugfix release. Only one new feature
has been added.
This release breaks fifo support in lyx:
$ lyx
LyXComm: Could not open pipe /home/ef/.lyx/lyxpipe.out
Device or resource busy
To reproduce, insert
Christopher Faylor wrote:
Should be fixed in the next snapshot.
Confirmed. Thanks.
--
Enrico
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On Fri, Mar 09, 2012 at 09:47:13AM +0100, Corinna Vinschen wrote:
On Mar 9 02:14, Enrico Forestieri wrote:
I would like to point out a regression, seemingly introduced in 1.7.10.
If a program is exec'ed after forking in a thread and the program is
a native Windows program, it (seemingly
On Fri, Mar 09, 2012 at 02:05:37PM +0100, Corinna Vinschen wrote:
On Mar 9 13:43, Corinna Vinschen wrote:
On Mar 9 11:32, Enrico Forestieri wrote:
On Fri, Mar 09, 2012 at 09:47:13AM +0100, Corinna Vinschen wrote:
On Mar 9 02:14, Enrico Forestieri wrote:
I would like to point
I would like to point out a regression, seemingly introduced in 1.7.10.
If a program is exec'ed after forking in a thread and the program is
a native Windows program, it (seemingly) fails to start.
Please, find attached a test case. You can try it with gvim, for example.
There's no problem with
Corinna Vinschen writes:
Would it be ok if it works the old way (WIN_A uses the Cygwin codeset)
for applications built under 1.7.9 and earlier, and the new way (WIN_A
uses Win32 ANSI/OEM codepage) for applications built under 1.7.10 and
later? That means the current lyx continues to work
Corinna Vinschen writes:
Which raises the question why the Cygwin version of lyx uses
cygwin_conv_path at all. Does it call Windows functions with the paths?
If so, why? If not, why are the paths converted to Windows?
Because the user *could* enter Windows paths (e.g., for including
Enrico Forestieri writes:
However, I experimented a bit with the last snapshot, and even using Greek
or Japanese characters in file names, lyx seems to be working fine.
Sorry, it was a cursory test. Actually, cygwin_conv_path is only called
for absolute paths. Using an absolute Windows path
Andy Koppe writes:
On 8 December 2011 00:33, Enrico Forestieri wrote:
Corinna Vinschen writes:
Just so it's clear why I did that, maybe you want to have a look into
the brief discussion on the cygwin-developers list:
http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html
All
Ken Brown writes:
I don't use lyx (though I use tex extensively), so maybe there's
something I don't understand. But is it really necessary for Cygwin's
lyx to support a native Windows tex?
Necessary? No. Useful? Yes.
Wouldn't it be more reasonable for
users of a native Windows tex to
Ken Brown writes:
On 12/8/2011 10:56 AM, Enrico Forestieri wrote:
[...]
Until recently, the only Cygwin TeX engine was teTeX, which does not
support XeTeX. If you wanted a Cygwin version of lyx, you could not
have used XeTeX, unless you used MikTeX, for example.
That changed a couple
Corinna Vinschen writes:
Just so it's clear why I did that, maybe you want to have a look into
the brief discussion on the cygwin-developers list:
http://cygwin.com/ml/cygwin-developers/2011-11/msg0.html
All good reasons, but you are going to break backward compatibility.
At least, lyx
On Mon, Feb 15, 2010 at 10:16:55PM -0500, Christopher Faylor wrote:
On Tue, Feb 16, 2010 at 02:20:55AM +0100, Enrico Forestieri wrote:
On Sun, Feb 14, 2010 at 08:54:27PM -0500, Christopher Faylor wrote:
I just checked in YA in my series of attempts to get this working right
On Sun, Feb 14, 2010 at 08:54:27PM -0500, Christopher Faylor wrote:
I just checked in YA in my series of attempts to get this working right.
It will behave marginally better now but there are still problems if you
attempt to write to a fifo before anything is reading it and then try to
do a
On Wed, Dec 23, 2009 at 03:12:19AM +0100, Enrico Forestieri wrote:
On Tue, Dec 22, 2009 at 07:37:14PM -0500, Christopher Faylor wrote:
On Tue, Dec 22, 2009 at 11:43:09PM +0100, Enrico Forestieri wrote:
I am experiencing a problem with select() and named pipes in cygwin
1.7. The attached
I am experiencing a problem with select() and named pipes in cygwin 1.7.
The attached test case segfaults on the select() call, but works fine
with both cygwin 1.5 and linux.
--
Enrico
#include stdio.h
#include stdlib.h
#include errno.h
#include sys/select.h
#include sys/types.h
#include
On Tue, Dec 22, 2009 at 07:37:14PM -0500, Christopher Faylor wrote:
On Tue, Dec 22, 2009 at 11:43:09PM +0100, Enrico Forestieri wrote:
I am experiencing a problem with select() and named pipes in cygwin
1.7. The attached test case segfaults on the select() call, but works
fine with both
On Wed, Nov 26, 2008 at 12:38:49PM -0500, Christopher Faylor wrote:
On Wed, Nov 26, 2008 at 03:50:52PM +0100, Enrico Forestieri wrote:
According to
http://www.opengroup.org/onlinepubs/95399/functions/open.html
the open() function shall fail and sets errno to ENXIO if
O_WRONLY | O_NONBLOCK
On Wed, Dec 09, 2009 at 10:41:09AM -0500, Christopher Faylor wrote:
On Wed, Dec 09, 2009 at 03:43:41PM +0100, Enrico Forestieri wrote:
Sorry for the very late reply and thanks for fixing the return code
from open(). However, this is still not posix compliant as errno is
set to ENOENT instead
According to
http://www.opengroup.org/onlinepubs/95399/functions/open.html
the open() function shall fail and sets errno to ENXIO if
O_WRONLY | O_NONBLOCK is set, the named file is a FIFO, and no
process has the file open for reading.
This is not the case on Cygwin, as demonstrated by the
Ismael Valladolid Torres writes:
On Mon, Mar 3, 2008 at 3:56 PM, Dave Korn dave.korn at artimi.com wrote:
On a UK keyboard (and I'm hoping it works on ESP as well) I press
Ctrl+']'.
Unfortunately on an spanish keyboard ']' is generated via AltGr and
not directly or via shift...
Try
Furash Gary writes:
So is there anything I can do for win cygwin?
Try replacing spaces ' ' with dots '.' in the paths specified with --prunepaths.
In a regexp a dot matches any character.
--
Enrico
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
Sean Daley writes:
Read further down that thread and you'll also see that people discovered some
additional horrifying things about windows cmd.
http://sourceware.org/ml/cygwin/2004-09/msg00277.html
Referring to that old post, the following works:
C:\cmd /c C:\Documents and
Larry Hall writes:
Enrico Forestieri wrote:
David Arnstein writes:
I just tried to use the Cygwin port of lyx. It cannot cope with my
home directory, which appears as //fs-sj1-15/darnstein in Cygwin. This
is a network directory, obviously.
When lyx starts up, it emits a complaint
David Arnstein writes:
I just tried to use the Cygwin port of lyx. It cannot cope with my
home directory, which appears as //fs-sj1-15/darnstein in Cygwin. This
is a network directory, obviously.
When lyx starts up, it emits a complaint
QSettings: error creating
On Sat, Oct 07, 2006 at 02:36:46PM +, Eric Blake wrote:
It appears that lyx is trying to access the root directory (/). It
does not seem to know how to interpret the Windows syntax //.
This is because lyx uses the boostfs library with BOOST_POSIX defined,
so any path of the form
45 matches
Mail list logo