So I was wondering if the Windows Subsystem For Linux, apparently part of
Windows 10 Anniversary Update, obsoletes Cygwin.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On Mon, Aug 29, 2016 at 12:00 PM, Schwarz, Konrad
wrote:
> So I was wondering if the Windows Subsystem For Linux, apparently part of
> Windows 10 Anniversary Update, obsoletes Cygwin.
>
That seems a *little* inflammatory to me. Since Windows Subsystem for
Linux can't inter-operate with Windows v
On 8/29/2016 10:06, Whek rin wrote:
> The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
> cannot by default find libraries from the path
> /usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
> mingw64-x86_64-runtime installs them. I believe this is a build
> configuratio
On 8/29/2016 7:15 AM, Ray Donnelly wrote:
> On Mon, Aug 29, 2016 at 12:00 PM, Schwarz, Konrad
> wrote:
>> So I was wondering if the Windows Subsystem For Linux, apparently part of
>> Windows 10 Anniversary Update, obsoletes Cygwin.
>>
> That seems a *little* inflammatory to me. Since Windows Su
From: Gene Pavlovsky
> Andrey,
> That's what I personally think, none of the scripts I use have CRs,
> and this is why I'd prefer not using the `igncr` option.
> However the recent change to how `read` works makes it necessary to
> modify existing scripts which interoperate with Windows console
>
On 8/27/2016 1:44 PM, Andrey Repin wrote:
> Greetings, Christian Franke!
>
>> Andrey Repin wrote:
Hmm... therefore it is also better to change the last line to:
.\bash --login -i
>>> "%~dp0bin\bash.exe" --login -i
>
>> Changing the directory before bash is run is a security measur
On 8/27/2016 12:15 PM, Andrey Repin wrote:
> Greetings, Gene Pavlovsky!
>
>> Looks like it's related to a recent change in bash, which is `read`
>> now honors Cygwin-specific `igncr` shell option (`set -o igncr`),
>> which I didn't enable.
>> Adding `set -o igncr` to the top of the script does the
On 8/28/2016 10:06 PM, Whek rin wrote:
> The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
> cannot by default find libraries from the path
> /usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
> mingw64-x86_64-runtime installs them. I believe this is a build
> configura
Any software add-on which aims to "replace Cygwin" will have to
address each and every use case for which Cygwin is currently chosen
by so many users.
Cygwin has made HUGE strides over the years and with every iteration
improves our efficiency as we interact with Windows. (Thank you,
Cygwin Maint
Greetings, Linda Walsh!
> Andrey Repin wrote:
>> Also, @ Linda, the string escaping is done by the shell before passing
>> arguments to the command, as I understand.
>> If I'm starting an application not from shell, the app, being a good citizen,
>> should not second-guess the arguments it is give
Greetings, cyg Simple!
> On 8/27/2016 1:44 PM, Andrey Repin wrote:
>> Greetings, Christian Franke!
>>
>>> Andrey Repin wrote:
> Hmm... therefore it is also better to change the last line to:
> .\bash --login -i
"%~dp0bin\bash.exe" --login -i
>>
>>> Changing the directory befor
Greetings, Schwarz, Konrad!
> So I was wondering if the Windows Subsystem For Linux, apparently part of
> Windows 10 Anniversary Update, obsoletes Cygwin.
Please don't start this flamewar again.
The topic was discussed to death, use search.
In short, the problem is that is an isolated subsystem.
> So I was wondering if the Windows Subsystem For Linux, apparently part of
> Windows 10 Anniversary Update, obsoletes Cygwin.
For a previous discussion of this, see the thread starting at
https://sourceware.org/ml/cygwin/2016-04/msg00244.html.
--
Problem reports: http://cygwin.com/proble
On 1/23/2016 6:30 PM, Ken Brown wrote:
This is a rebuild of the 24.5-2 packages, patched to allow native
Windows paths like C:\foo or C:/foo in situations where file names are
expected.
For the sake of the archives, I'm announcing here that I consider this
experimental release to be a failure[
jeff writes:
>> Hopefully this solves the problem reported in:
>> https://cygwin.com/ml/cygwin/2016-08/msg0.html
>>
>>
> The problem has been resolved, and all of my code now compiles.
Thanks for the confirmation.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
On 08/28/2016 03:20 PM, Gene Pavlovsky wrote:
> Re-posting a reply I got from Henri (aka Houder) hou...@xs4all.nl
> His letter follows:
>
> Hi Gene,
>
> Reread your entry to the mailing list ...
>
>> Apparently the latest bash in Cygwin modified the read builtin to use
>> Cygwin-specific shell o
On 08/26/2016 06:49 PM, Gene Pavlovsky wrote:
> After I updated Cygwin yesterday, a daily database backup bash script
> (`automysqlbackup`) broke.
> My previous bash was 4.3.42-4 (installed when I updated Cygwin on
> 2016/07/23), current is 4.3.46-7.
> Here's the code snippet:
> ```bash
> local i
Hi,
I am not sure if this is a bug: running a xlsx2tex conversion
ssconvert --export-type=Gnumeric_html:latex a.xlsx a.tex
results in the error messages
** (ssconvert:12292): WARNING **: Unable to open module file
"/usr/lib/gnumeric/1.12.31/plugins/fn-math/xlcall32"
On August 29, 2016 at 01:18 ben...@gmail.com (Ben Altman) wrote:
>
> This comes a while later but I was wrong and you were right.
>
Glad to be of service.
--
-Barry Shein
Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voic
System details first: "CYGWIN_NT-5.1 GKDC531 2.5.2(0.297/5/3) 2016-06-23
14:27 i686" on Windows XP SP3, on a dual-core Pentium 4 (i786) box.
I have rebuilt and optimized gcc and several math libraries with the
architecture-specific options of gcc, `-march=native' and
`-mfpmath=sse', to get the
Greetings, Eric Blake!
> But it seems like \n handling in PS1 is independent of any change in
> handing in the 'read' builtin. As evidence, I ran the following test
> using the older bash-4.3.42-4 build:
> $ bash-4.3.42-4
> $ set -o igncr
> $ PS1='$(date)\n# '
> bash: command substitution: line
On 2016-08-29 21:21, Nirgendsdorf wrote:
I am sure I have all the support libraries for the 32-bit mingw gcc
installed and working (I've built software with it). Does this mean a
64-bit machine is required to build the Cygwin DLL?
No; the mingw64 cross-compiler is required for building cyglsa64
22 matches
Mail list logo