2014-10-24 22:16, Christian Franke wrote:
>
> Corinna Vinschen wrote:
>>
>> Sigh.
>>
>> I don't like the idea either that this simple change breaks existing
>> scenarios. I'm inclined to revert this change.
>>
>> Christian, would you mind terribly to re-add the tweak to postfix
>> to set $PATH
On Oct 24 22:16, Christian Franke wrote:
> Corinna Vinschen wrote:
> >[Christian, please chime in]
> >
> >On Oct 24 20:41, Denis Excoffier wrote:
> >>> From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
> >>>makes sense that the system DLLs in /bin cannot be overridden, unless
>
I use a Vim plugin called clang_complete for C/C++ code completion which
interfaces with Clang using Clang's python bindings. After updating Cygwin,
the terminal output of Vim is garbled as soon as the plugin uses the Clang
Python bindings.
I tracked down the exact revision (188615) of LLVM/Clang
Corinna Vinschen wrote:
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
From Cygwin's POV {/usr}/bin is a system dir. For security reasons it
makes sense that the system DLLs in /bin cannot be overridden, unless
it's an installation issue which should be covered by lookin
On Oct 24 21:52, Corinna Vinschen wrote:
> Hi Cygwin friends and users,
>
>
> I just released a 2nd TEST version of the next upcoming Cygwin release,
> 1.7.33-0.2.
>
> This test version comes with a few changes compared to the former test
> version 1.7.33-0.2:
Grr. Make that 1.7.33-0.1 here.
Hi Cygwin friends and users,
I just released a 2nd TEST version of the next upcoming Cygwin release,
1.7.33-0.2.
This test version comes with a few changes compared to the former test
version 1.7.33-0.2:
- New API: stime (SVr4).
- Provide Cygwin documentation (PDFs and HTML) for offline usage
[Christian, please chime in]
On Oct 24 20:41, Denis Excoffier wrote:
> > On 2014-10-24 13:02, Corinna Vinschen wrote:
> > On Oct 23 20:06, Denis Excoffier wrote:
> >> On 2014-10-22 11:23, Corinna Vinschen wrote:
> >>>
> >>> - Drop the current working directory from the default DLL search path in
On Oct 24 20:20, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
> > For your convenience I wrote new documentation. Since this is a TEST
> > prerelease, the new documentation is not part of the official docs yet.
> > Rather have a look at
>
> > https://cygwin.com/preliminary-ntsec.html
>
> On 2014-10-24 13:02, Corinna Vinschen wrote:
>
> On Oct 23 20:06, Denis Excoffier wrote:
>> On 2014-10-22 11:23, Corinna Vinschen wrote:
>>>
>>> - Drop the current working directory from the default DLL search path in
>>> favor of Cygwin's /bin dir.
>> I'm not so comfortable with this one.
>>
Am 24.10.2014 19:28, schrieb Keith Christian:
Here's a function for you Andrey, in appreciation for all the work you
contribute to Cygwin:
type uname_r
uname_r is a function
uname_r ()
{
uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}
uname_r
1_7_32_0_274_5_3
How abo
On 10/24/2014 11:28 AM, Keith Christian wrote:
> uname_r ()
> {
> uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
> }
Or for one less fork and less typing:
uname_r ()
{
uname -r | sed 's/[.(/\)]/_/g; s/_$//'
}
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt vi
Here's a function for you Andrey, in appreciation for all the work you
contribute to Cygwin:
type uname_r
uname_r is a function
uname_r ()
{
uname -r | sed -e 's/[.(/\)]/_/g' | sed -e 's/\(.*\)\(_$\)/\1/'
}
uname_r
1_7_32_0_274_5_3
On Fri, Oct 24, 2014 at 10:20 AM, Andrey Repin wrote:
> From: Eric Blake
> On 10/24/2014 09:19 AM, John Wiersba wrote:
>
>> I thought that all (or virtually all) cygwin-supplied programs that start
>> other programs use the cygwin1.dll execve(2) emulation to start them,
> because
>> the execve emulation can be used to start *both* cygwin progr
Greetings, Corinna Vinschen!
> For your convenience I wrote new documentation. Since this is a TEST
> prerelease, the new documentation is not part of the official docs yet.
> Rather have a look at
> https://cygwin.com/preliminary-ntsec.html
"via an undocumented APIr " should be "... API, " p
On 10/24/2014 09:19 AM, John Wiersba wrote:
> I thought that all (or virtually all) cygwin-supplied programs that start
> other programs use the cygwin1.dll execve(2) emulation to start them, because
> the execve emulation can be used to start *both* cygwin programs and windows
> native program
> From: Corinna Vinschen
>
> On Oct 24 06:05, John Wiersba wrote:
>
>> I would have thought cygwin1.dll contains the code necessary to do this,
> like the linux kernel does. Can it be added to the dll or does it have to be
> added to each executable individually, such as bash.exe, run.exe, e
Sorry to report, but it would seem the new Cygwin versions break "bind-utils
9.9.5-3 -- 9.9.6-2" ability to stdout stdin.
Tested on:
CYGWIN_NT-6.1 1.7.32 - 1.7.33(0.278/5/3) 2014-10-22 10:37 x86_64 Cygwin
(w2k8r2)
CYGWIN_NT-6.3 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin (2012r2)
I
On Oct 24, 2014, at 7:37 AM, Andrey Repin wrote:
> run.exe is designed to start Windows
> applications (or associations).
…or associations?
Are you confusing run.exe with cygstart.exe?
$ touch foo.txt
$ run foo.txt
run FATAL: Could not start C:\cygwin64\home\Warren\foo.txt
$ cygstart foo.txt
On Oct 24, 2014, at 7:57 AM, Eric Blake wrote:
> On 10/24/2014 07:53 AM, Corinna Vinschen wrote:
>> On Oct 24 06:05, John Wiersba wrote:
>>> I would have thought cygwin1.dll contains the code necessary to do this,
>>> like the linux kernel does.
>>
>> run.exe doesn't start the executable via a
On 10/24/2014 07:53 AM, Corinna Vinschen wrote:
> On Oct 24 06:05, John Wiersba wrote:
>> I would have thought cygwin1.dll contains the code necessary to do this,
>> like the linux kernel does. Can it be added to the dll or does it have to
>> be added to each executable individually, such as bas
On Oct 24 06:05, John Wiersba wrote:
> I would have thought cygwin1.dll contains the code necessary to do this, like
> the linux kernel does. Can it be added to the dll or does it have to be
> added to each executable individually, such as bash.exe, run.exe, etc.?
>
> bash$ /bin/run ./try
>
On Oct 24 14:54, Corinna Vinschen wrote:
> On Oct 24 12:05, Jon TURNEY wrote:
> > On 23/10/2014 16:37, Corinna Vinschen wrote:
> > >On Oct 23 08:04, Ken Brown wrote:
> > >>Yes, flags register corruption is exactly what Eli suggested in the other
> > >>bug report I cited.
> > >
> > >The aforemention
Greetings, John Wiersba!
> I would have thought cygwin1.dll contains the code necessary to do this,
> like the linux kernel does. Can it be added to the dll or does it have to
> be added to each executable individually, such as bash.exe, run.exe, etc.?
> bash$ /bin/run ./try
> run FATAL: Cou
I would have thought cygwin1.dll contains the code necessary to do this, like
the linux kernel does. Can it be added to the dll or does it have to be added
to each executable individually, such as bash.exe, run.exe, etc.?
bash$ /bin/run ./try
run FATAL: Could not start D:\ftp\try
--
Proble
On Oct 24 12:05, Jon TURNEY wrote:
> On 23/10/2014 16:37, Corinna Vinschen wrote:
> >On Oct 23 08:04, Ken Brown wrote:
> >>Yes, flags register corruption is exactly what Eli suggested in the other
> >>bug report I cited.
> >
> >The aforementioned patch was supposed to fix this problem and it is
> >
Greetings, Don MacDougall!
>> I wouldn't try to restart the install without figuring out why
>> /etc/postinstall/texlive-collection-basic.sh didn't complete. Is there
>> anything
>> at all in /var/log/ that might provide a clue? Usually setup writes
>> temporary
>> files while it's executing pos
On 23/10/2014 16:37, Corinna Vinschen wrote:
On Oct 23 08:04, Ken Brown wrote:
On 10/23/2014 7:31 AM, Jon TURNEY wrote:
On 20/10/2014 14:03, Ken Brown wrote:
Or is there some other plausible explanation for "impossible" crashes?
This can't just be a result of a gdb bug, because in at least one
On Oct 23 20:06, Denis Excoffier wrote:
> On 2014-10-22 11:23, Corinna Vinschen wrote:
> >
> > - Drop the current working directory from the default DLL search path in
> > favor of Cygwin's /bin dir.
> I'm not so comfortable with this one.
>
> I use
> PATH=/my/dir/bin:/usr/bin /my/otherdir/mypro
On Oct 24 17:35, Luke Kendall wrote:
> On 24/10/14 02:43, Corinna Vinschen wrote:
> > On Oct 22 20:57, Tom Schutter wrote:
> >> On Wed 2014-10-22 11:23, Corinna Vinschen wrote:
> >>> For your convenience I wrote new documentation. Since this is a TEST
> >>> prerelease, the new documentation is not
On Oct 23 20:01, Achim Gratz wrote:
> Achim Gratz writes:
> > Corinna Vinschen writes:
> >> In theory, no. The last OpenSSH update, 6.7p1-1, alreadyd contained
> >> the upstream fix to work with local sshd accounts which have the
> >> machine name prepended.
> >
> > I will check this tomorrow, I s
On Oct 23 19:21, Thomas Wolff wrote:
> Am 23.10.2014 17:36, schrieb Corinna Vinschen:
> >On Oct 23 14:42, Thomas Wolff wrote:
> >>Am 22.10.2014 16:00, schrieb Corinna Vinschen:
> >>>On Oct 22 09:01, Thomas Wolff wrote:
> I'm facing a number of issues with case-sensitivity which I've collected:
On Oct 23 21:07, Ken Brown wrote:
> On 10/23/2014 4:32 PM, Ken Brown wrote:
> >On 10/23/2014 11:37 AM, Corinna Vinschen wrote:
> >>On Oct 23 08:04, Ken Brown wrote:
> >>>On 10/23/2014 7:31 AM, Jon TURNEY wrote:
> On 20/10/2014 14:03, Ken Brown wrote:
> >Or is there some other plausible expl
> I wouldn't try to restart the install without figuring out why
> /etc/postinstall/texlive-collection-basic.sh didn't complete. Is there
> anything
> at all in /var/log/ that might provide a clue? Usually setup writes
> temporary
> files while it's executing postinstall scripts.
There wasn't ev
33 matches
Mail list logo
