Dear Blake,
> External products were being lazy by relying on cygwin to strip CR when they
> should have stripped it themselves. But 'sed -b' does NOT strip CR (it is the
> exact opposite, of keeping CR unstripped).
I think that there are more people who use sed for text processing in a MinGW
c
On Jun 8 16:46, Houder wrote:
> Hi Corinna,
>
> Maybe you are still around ... otherwise it will be for the next round.
>
> During my exercise with sshd I was "forced" :-) to study the User Guide, as I
> am not "well informed" :-P about the security model of Windows.
>
> I am referring to this
Greetings, Garber, Dave (GE Oil & Gas, Non-GE)!
> Looks good. I did fond one other behavior that I believe should be
> changed. When you are typing in the search box, if you press the enter key,
> it's the same as pressing the Next button and starts the install. My $.02
> is that Enter should b
>> /usr/bin/xterm: Xt error: Can't open display: :0.0
>> /usr/bin/xterm: DISPLAY is not set
Thanks for all suggestions. Both the following fragments seem to work
flawlessly. Both incorporate a waiting time for XWin to gain traction
before xterm is called:
1. Starting a xterm console from a .cmd f
On Fri, 9 Jun 2017 11:00:36, Corinna Vinschen wrote:
[snip]
> You're not supposed to do that. setuid() is a privileged call, so it's
> supposed to be called by a privileged process only. Do not add these
> permissions to a normal user account unless you exactly know what you're
> doing security-
On Tue, Jun 6, 2017 at 9:22 PM, Corinna Vinschen wrote:
> On Jun 6 17:57, Corinna Vinschen wrote:
>> > > On Wed, May 10, 2017 at 11:30:46AM +0200, Erik Bray wrote:
>> > >> [...]
>> > >> The attached test demonstrates the bug. Given an output buffer of N
>> > >> wide characters, wcsxfrm will cause
On 2017-06-08 02:50, Soegtrop, Michael wrote:
>> No, the documented behavior is that CR-LF is converted to LF only
>> for text- mounted files; but pipelines are default binary-mounted.
>> If you want to strip CR from a pipeline, then make it explicit.
>>> var=$( prog | sed .)
>> Rewrite that to va
On 6/9/2017 4:06 AM, Soegtrop, Michael wrote:
> Dear Blake,
>
>> External products were being lazy by relying on cygwin to strip CR when they
>> should have stripped it themselves. But 'sed -b' does NOT strip CR (it is
>> the
>> exact opposite, of keeping CR unstripped).
>
> I think that there
Dear cyg Simple,
> but it would be most beneficial if you caused the stdio of your
> Windows applications to be in binary format instead of text format. Then the
> CR wouldn't be an issue during the pipe process. Why does your applications
> stdio need to be in text format instead of binary form
Dear Brian,
> alias sed='sed -b -e '\''s/\r$//'\'''
thanks, an interesting idea! Putting this into something like .bashrc might
have a similar effect as having a special sed build with CR stripping built in.
Best regards,
Michael
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 855
Greetings, Soegtrop, Michael!
> Why should anybody use "wb" mode to open a file in a Linux centric app
Because it removes ambiguity.
Everybody should use binary IO unless they explicitly want text behavior.
Not just because they don't care.
--
With best regards,
Andrey Repin
Friday, June 9, 20
Greetings, Soegtrop, Michael!
>> alias sed='sed -b -e '\''s/\r$//'\'''
> thanks, an interesting idea! Putting this into something like .bashrc might
> have a similar effect as having a special sed build with CR stripping built
> in.
Except it may not work in makefiles, since make calls sed dire
On Fri, Jun 9, 2017 at 8:31 AM, Andrey Repin wrote:
> Greetings, Soegtrop, Michael!
>
>>> alias sed='sed -b -e '\''s/\r$//'\'''
>
>> thanks, an interesting idea! Putting this into something like .bashrc might
>> have a similar effect as having a special sed build with CR stripping built
>> in.
>
On 06/09/2017 10:01 AM, Soegtrop, Michael wrote:
> Dear cyg Simple,
>
>> but it would be most beneficial if you caused the stdio of your
>> Windows applications to be in binary format instead of text format. Then the
>> CR wouldn't be an issue during the pipe process. Why does your applications
On 06/09/2017 10:31 AM, Andrey Repin wrote:
> Greetings, Soegtrop, Michael!
>
>>> alias sed='sed -b -e '\''s/\r$//'\'''
>
>> thanks, an interesting idea! Putting this into something like .bashrc might
>> have a similar effect as having a special sed build with CR stripping built
>> in.
>
> Exce
On Thu, Jun 8, 2017 at 7:39 PM, yyjdelete wrote:
> Tested with:
> cygwin: 2.8.0-1
> bash: 4.4.12-3
> win: 10 16199(Insider)
>
> When you type `1234567890(Enter)(Enter)(Enter)`, the bash only get `1470`,
> and nothing is shown before the third Enter is press.
>
> It work well after switch to
Dear Dan,
> One could try making a wrapper shell script where sed usually lives that adds
> those options and calls the real sed...
I tried to do exactly this, but I tried to pipe a dos2unix command in between.
It got a bit complicated because I had to parse the sed command line arguments.
The
Dear Eric,
> Building mingw apps may be one use of cygwin, but it is not the "intended use
> case".
I said "an" intended use case, not "the". I also use cygwin for a lot of other
things.
> If you are writing a Linux app that processes data produced on a windows
> machine, then YOU must strip C
Am 09.06.2017 um 18:56 schrieb Soegtrop, Michael:
Maybe my situation gets clear when I describe what my use case is: I
maintain the scripts which build the Windows installers for Coq - a
proof assistant with a GTK based UI. This starts building a MinGW
OCaml compiler from sources.
You're doin
On Fri, Jun 9, 2017 at 2:42 PM, Hans-Bernhard Bröker wrote:
>> I don't see another way than having sed strip away the CRs. It
>> doesn't make sense to build programs intended to be run under plain
>> Windows such that they do not produce CRs.
>
>
> I believe it makes much more sense than you think.
The following packages have been uploaded to the Cygwin distribution:
* texlive-20170520-2
* libkpathsea6-20170520-2
* libkpathsea-devel-20170520-2
* libptexenc1-20170520-2
* libptexenc-devel-20170520-2
* libsynctex1-20170520-2
* libsynctex-devel-20170520-2
* libtexlua52_5-20170520-2
* libtexlua5
On 6/7/2017 2:21 AM, Lloyd Wood via cygwin wrote:
download geomview 1.9.5 from http://www.geomview.org
this used to build on cygwin 32-bit.
I've just build geomview-1.9.5 on both 32-bit and 64-bit Cygwin, using
the attached cygport file and patches.
If it works well, I'll propose it for incl
I'm using cygwin on Windows 7, setup.exe version 2.879 (64 bit).
I updated my packages yesterday, and now Babel in LaTeX is having
trouble. The line:
\usepackage[USenglish]{babel}
is eliciting the following error message:
! Package babel Error: Unknown option `USenglish'. Either you misspelled
Dear Hans-Bernhard,
> You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a
> _native_ toolchain. That begs the question: why are you doing a cross build
> in
> the first place?
I simply couldn't find another way to build 50 configure / make style libraries
and tools on Win
I just had to debug & fix a problem from the sed behavior change that
has little to do with MinGW.
I'm running a native version of Emacs and have makefiles, lots of
scripts, and various commands in my makefiles for extracting
dependencies. The commands use sed, gawk, ..., and started creating
bad
On Fri, Jun 9, 2017 at 11:28 PM, Soegtrop, Michael
wrote:
> Dear Hans-Bernhard,
>
>> You're doing this via Cygwin, i.e. on a Windows machine, where MinGW is a
>> _native_ toolchain. That begs the question: why are you doing a cross build
>> in
>> the first place?
>
> I simply couldn't find anoth
Hi Ken,
thanks for this - both 32-bit and 64-bit Geomview from
your repository work as expected. I was able to run
SaVi (http://savi.sf.net/) under both, with OpenGL and
piping between Geomview and SaVi working so that
SaVi could control Geomview.
(64-bit working with SaVi was a pleasant surprise
On 6/9/2017 5:58 PM, Harvey Stein wrote:
I'm using cygwin on Windows 7, setup.exe version 2.879 (64 bit).
I updated my packages yesterday, and now Babel in LaTeX is having
trouble. The line:
\usepackage[USenglish]{babel}
is eliciting the following error message:
! Package babel Error: Unknow
On 6/9/2017 7:22 PM, Lloyd Wood wrote:
Hi Ken,
thanks for this - both 32-bit and 64-bit Geomview from
your repository work as expected. I was able to run
SaVi (http://savi.sf.net/) under both, with OpenGL and
piping between Geomview and SaVi working so that
SaVi could control Geomview.
Hi Lloy
29 matches
Mail list logo
