On 3/15/2019 7:59 PM, Brian Inglis wrote:
> On 2019-03-15 04:03, Soegtrop, Michael wrote:
>
>> you are mixing a DOS echo which will produce a \r\n line ending with a
>> Cygwin sed which expects \n line endings. The second . matches the \r.
>> Either work in bash and use Cygwin echo or use a MinG
On 2019-03-15 04:03, Soegtrop, Michael wrote:
> you are mixing a DOS echo which will produce a \r\n line ending with a
> Cygwin sed which expects \n line endings. The second . matches the \r.
> Either work in bash and use Cygwin echo or use a MinGW compile of sed or
> strip the \r e.g. with tr or
Hi Michael.
you are mixing a DOS echo which will produce a \r\n line ending with a Cygwin
sed which expects \n line endings.
I already thought it's something about EOL, just wanted to make sure if this is
not a bug. Thanks.
--
Timo
--
Problem reports: http://cygwin.com/problems.html
Dear Timo,
you are mixing a DOS echo which will produce a \r\n line ending with a Cygwin
sed which expects \n line endings. The second . matches the \r.
Either work in bash and use Cygwin echo or use a MinGW compile of sed or strip
the \r e.g. with tr or maybe match it more explicitly with a \r
On 15. 3. 2019 10:51, Timo Maier wrote:
Why do I need a second "." in the cygwin sed?
Hi Timo.
The difference is in echo.
$ /bin/echo "Hey" | /usr/bin/hexdump -C
48 65 79 0a |Hey.|
0004
C:\>echo Hey| c:\cygwin\bin\hexdump -C
48 65
On 2018-03-06 07:01, Fergus Daly wrote:
>>> I looked for recent similar issues and only found
> https://superuser.com/questions/1297658/folder-names-become-uppercase-when-syncing-to-fat32-drive
Have you checked that you get identical behaviour under cmd shell or PowerShell,
and see the problem usi
>> I looked for recent similar issues and only found
https://superuser.com/questions/1297658/folder-names-become-uppercase-when-syncing-to-fat32-drive
>> So if other users of this Win10 build start tripping on this same problem
>> and reporting it, it may get looked at by MS.
The site you mentio
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
> Sent: March 5, 2018 2:55 PM
> To: cygwin@cygwin.com
> Subject: Re: sed seems to force UC filename on Mixed 8.3 filenames on
> FAT32
>
> On M
On Mar 5 12:46, Michel LaBarre wrote:
> Sorry folks but I am going to top post for the sake of clarity. The original
> msg is below for reference.
>
> Corinna, I ran the following and I attached the trace file:
> E:\junk>ls > Zot.txt
> E:\junk>ls
> Zot.txt
> E:\junk>stra
On Mar 5 12:05, Michel LaBarre wrote:
> > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> > Behalf Of Corinna Vinschen
> > On Mar 5 11:42, Michel LaBarre wrote:
> > > I have the same build 16299.248 and I get the same behaviour.
> > > Perhaps consider: http://www.zoneutils.com
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Corinna Vinschen
>
> On Mar 5 11:42, Michel LaBarre wrote:
> >
> > > Behalf Of Fergus Daly
> > > Starting to look exactly like that. On Windows 7 there is no problem.
> > > On earlier W1
On Mar 5 11:42, Michel LaBarre wrote:
>
>
> > -Original Message-
> > From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> > Behalf Of Fergus Daly
> > Sent: March 5, 2018 4:06 AM
> > To: The Cygwin Mailing List
> > Subject: Re: s
> -Original Message-
> From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On
> Behalf Of Fergus Daly
> Sent: March 5, 2018 4:06 AM
> To: The Cygwin Mailing List
> Subject: Re: sed seems to force UC filename on Mixed 8.3 filenames on
> FAT32
>
> &
>> ..."or operation on FAT32 was changed by Windows updates."
Starting to look exactly like that. On Windows 7 there is no problem.
On earlier W10 machines in this office there is no problem. My machine
underwent a massive (time-consuming) update on or around 13-FEB to
Microsoft Windows Version 17
On 2018-03-04 10:05, cyg Simple wrote:
> On 3/4/2018 11:14 AM, Brian Inglis wrote:
>> On 2018-03-04 03:09, Corinna Vinschen wrote:
>>> On Mar 3 11:14, Brian Inglis wrote:
On 2018-03-03 01:36, Fergus Daly wrote:
>>> Run stat on original and converted files.
>
> OK. I get this:
On 3/4/2018 11:14 AM, Brian Inglis wrote:
> On 2018-03-04 03:09, Corinna Vinschen wrote:
>> On Mar 3 11:14, Brian Inglis wrote:
>>> On 2018-03-03 01:36, Fergus Daly wrote:
>> Run stat on original and converted files.
OK. I get this:
~> stat /j/PStart.xml
File: /j/PSt
On 2018-03-04 03:09, Corinna Vinschen wrote:
> On Mar 3 11:14, Brian Inglis wrote:
>> On 2018-03-03 01:36, Fergus Daly wrote:
> Run stat on original and converted files.
>>>
>>> OK. I get this:
>>>
>>> ~> stat /j/PStart.xml
>>> File: /j/PStart.xml
>>> Size: 7233Blocks: 8
On Mar 3 11:14, Brian Inglis wrote:
> On 2018-03-03 01:36, Fergus Daly wrote:
> >>> Run stat on original and converted files.
> >
> > OK. I get this:
> >
> > ~> stat /j/PStart.xml
> > File: /j/PStart.xml
> > Size: 7233Blocks: 8 IO Block: 65536 regular file
> > Device: a
On 2018-03-03 01:36, Fergus Daly wrote:
>>> Run stat on original and converted files.
>
> OK. I get this:
>
> ~> stat /j/PStart.xml
> File: /j/PStart.xml
> Size: 7233Blocks: 8 IO Block: 65536 regular file
> Device: a6418e7fh/2789314175d Inode: 7206475022584976007 Link
>> Run stat on original and converted files.
OK. I get this:
~> stat /j/PStart.xml
File: /j/PStart.xml
Size: 7233Blocks: 8 IO Block: 65536 regular file
Device: a6418e7fh/2789314175d Inode: 7206475022584976007 Links: 1
Access: (0644/-rw-r--r--) Uid: (197609/ fergusd)
Greetings, Brian Inglis!
> Does FAT support ACLs?
No.
--
With best regards,
Andrey Repin
Friday, March 2, 2018 20:46:37
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwi
On 2018-03-02 02:41, Fergus Daly wrote:
> .. AND dos2unix:
> ~> ls -al /j/P*
> -rw-r--r-- 1 dell ferg 6767 Mar 2 09:15 /j/PStart.xml
> ~> dos2unix /j/PStart.xml
> dos2unix: converting file /j/PStart.xml to Unix format...
> ~> ls -al /j/P*
> -rw-r--r-- 1 dell ferg 6767 Mar 2 09:16 /j/PSTART.XM
.. AND dos2unix:
~> ls -al /j/P*
-rw-r--r-- 1 dell ferg 6767 Mar 2 09:15 /j/PStart.xml
~> dos2unix /j/PStart.xml
dos2unix: converting file /j/PStart.xml to Unix format...
~> ls -al /j/P*
-rw-r--r-- 1 dell ferg 6767 Mar 2 09:16 /j/PSTART.XML
So something a bit major seems to be going on .. .
On Sat, 6 Jan 2018 16:25:20, Steve Harlow wrote:
Do I not have some environment variable set correctly? Is this a bug in sed?
I see that I can install the older version, 4.2.2.3. Looks like that
might take a step backwards on some libraries too. compiler-rt(5.0.1-1),
libc++devel (5.0.1-1), li
cyg Simple gmail.com> writes:
> $ TEST=`echo 'c:\windows' | sed -e s.\\..g`
> $ echo $TEST
> c:\\windows
>
> TEST=`echo 'c:\windows' | sed -e s.\\\.\.g'
> echo $TEST
>
> $ bash -x sed.sh
> ++ echo 'c:\windows'
> ++ sed -e 's.\.\g'
> sed -e expression #1, char 7: unterminated 's' command
On 11/14/14, 9:20 AM, "cyg Simple" wrote:
>$ TEST=`echo 'c:\windows' | sed -e s.\\..g`
>$ echo $TEST
>c:\\windows
>
>
>TEST=`echo 'c:\windows' | sed -e s.\\\.\.g'
>echo $TEST
>
>
>$ bash -x sed.sh
>++ echo 'c:\windows'
>++ sed -e 's.\.\g'
>sed -e expression #1, char 7: unterminated 's' co
On 14/11/14 17:20, cyg Simple wrote:
$ TEST=`echo 'c:\windows' | sed -e s.\\..g`
$ echo $TEST
c:\\windows
TEST=`echo 'c:\windows' | sed -e s.\\\.\.g'
echo $TEST
$ bash -x sed.sh
++ echo 'c:\windows'
++ sed -e 's.\.\g'
sed -e expression #1, char 7: unterminated 's' command
+ TEST=
+ ec
On 14/11/2014 17:20, cyg Simple wrote:
> $ TEST=`echo 'c:\windows' | sed -e s.\\..g`
> $ echo $TEST
> c:\\windows
>
>
> TEST=`echo 'c:\windows' | sed -e s.\\\.\.g'
> echo $TEST
>
>
> $ bash -x sed.sh
> ++ echo 'c:\windows'
> ++ sed -e 's.\.\g'
> sed -e expression #1, char 7: unterminate
On Jun 27 17:51, Corinna Vinschen wrote:
> On Jun 27 10:42, Yaakov (Cygwin/X) wrote:
> > On 2013-06-27 09:49, Corinna Vinschen wrote:
> > >Ok, here's me, even more puzzled. FIW, the 4.2.2 packages have *not*
> > >been built the same way as the 4.2.1 package. The difference is running
> > >autorec
On Jun 27 10:42, Yaakov (Cygwin/X) wrote:
> On 2013-06-27 09:49, Corinna Vinschen wrote:
> >Ok, here's me, even more puzzled. FIW, the 4.2.2 packages have *not*
> >been built the same way as the 4.2.1 package. The difference is running
> >autoreconf (4.2.2) vs. not running autoreconf (4.2.1).
>
On 2013-06-27 09:49, Corinna Vinschen wrote:
Ok, here's me, even more puzzled. FIW, the 4.2.2 packages have *not*
been built the same way as the 4.2.1 package. The difference is running
autoreconf (4.2.2) vs. not running autoreconf (4.2.1).
Were these natively compiled or cross-compiled? The
On Jun 27 16:49, Corinna Vinschen wrote:
> On Jun 27 16:24, Corinna Vinschen wrote:
> > On Jun 27 13:28, Paul Becker wrote:
> > > > From: On Behalf Of Corinna Vinschen
> > > > Sent: Thursday, June 27, 2013 6:49 AM
> > > > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> > > >
> > > > I've just updat
On Jun 27 16:24, Corinna Vinschen wrote:
> On Jun 27 13:28, Paul Becker wrote:
> > > From: On Behalf Of Corinna Vinschen
> > > Sent: Thursday, June 27, 2013 6:49 AM
> > > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> > >
> > > I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.
On Jun 27 13:28, Paul Becker wrote:
> > From: On Behalf Of Corinna Vinschen
> > Sent: Thursday, June 27, 2013 6:49 AM
> > Subject: [ANNOUNCEMENT] Updated: sed-4.2.2-2
> >
> > I've just updated the Cygwin 32 and 64 bit version of sed to 4.2.2-2.
>
> Since this 'sed' change, I noticed that "$" does
Corinna Vinschen wrote:
On Feb 21 11:58, cygwin@munub.e4ward.com wrote:
see here:
http://stackoverflow.com/questions/9368783/cygwin-bash-sed-locks-my-files
When I change files in cygwin bash with the sed command, the file gets locked.
Reproduce:
Open cmd and cd to non-user directory
On Feb 21 11:58, cygwin@munub.e4ward.com wrote:
> see here:
> http://stackoverflow.com/questions/9368783/cygwin-bash-sed-locks-my-files
>
> When I change files in cygwin bash with the sed command, the file gets locked.
>
> Reproduce:
>
> Open cmd and cd to non-user directory (f.e. temp)
On Feb 15 01:13, Andrey Repin wrote:
> Greetings, Earnie Boyd!
>
> >>> The standard response to issues dealing with CRLF files is to point the
> >>> user to dos2unix and text mode mounts. This should be adequate without
> >>> the hidden behavior of sed/grep/awk and probably others.
> >>
> >> While
Greetings, Earnie Boyd!
>>> The standard response to issues dealing with CRLF files is to point the
>>> user to dos2unix and text mode mounts. This should be adequate without
>>> the hidden behavior of sed/grep/awk and probably others.
>>
>> While your reasoning is sound, I prefer them to behave t
On Mon, Feb 13, 2012 at 7:56 PM, Andrey Repin wrote:
> Greetings, Nellis, Kenneth!
>
>> The standard response to issues dealing with CRLF files is to point the
>> user to dos2unix and text mode mounts. This should be adequate without
>> the hidden behavior of sed/grep/awk and probably others.
>
> W
Greetings, Nellis, Kenneth!
> The standard response to issues dealing with CRLF files is to point the
> user to dos2unix and text mode mounts. This should be adequate without
> the hidden behavior of sed/grep/awk and probably others.
While your reasoning is sound, I prefer them to behave the way
On Mon, Feb 13, 2012 at 2:48 PM, Paolo Bonzini wrote:
>
> If you meant that "rt" should be restricted to cygwin, that's also fine by
> me but in general I prefer feature tests to OS tests.
>
Then it becomes Cygwin's problem. I'm going to quote from
http://msdn.microsoft.com/en-us/library/yeby3zcb
On 02/13/2012 08:42 PM, John Cowan wrote:
> By the way, I'm still opening the script file with "rt". I cannot think
> of any case when you would want to keep CRs there.
You wouldn't, but the point is that "rt" isn't defined on Posix systems.
If it happens to be the same as "r", good, but that i
Paolo Bonzini scripsit:
> By the way, I'm still opening the script file with "rt". I cannot think
> of any case when you would want to keep CRs there.
You wouldn't, but the point is that "rt" isn't defined on Posix systems.
If it happens to be the same as "r", good, but that isn't guaranteed.
On 02/13/2012 04:43 PM, Earnie Boyd wrote:
>
> By the way, I'm still opening the script file with "rt". I cannot think of
> any case when you would want to keep CRs there.
The case of
sed -e 's/something/nothing/g' myfile > myfile2
as it works in Cygwin today would mean that in the case of th
Earnie Boyd skrev 2012-02-13 16:43:
> On Mon, Feb 13, 2012 at 10:22 AM, Paolo Bonzini wrote:
>> On 02/13/2012 03:56 PM, Corinna Vinschen wrote:
>>>
As long as it's consistent with coreutils I'll certainly do the change.
>>>
>>> Thanks! Would you mind to CC the cygwin list when the next upstr
On Mon, Feb 13, 2012 at 10:22 AM, Paolo Bonzini wrote:
> On 02/13/2012 03:56 PM, Corinna Vinschen wrote:
>>
>> > As long as it's consistent with coreutils I'll certainly do the change.
>>
>> Thanks! Would you mind to CC the cygwin list when the next upstream
>> sed release is available?
>
>
> Sur
On Feb 13 16:22, Paolo Bonzini wrote:
> On 02/13/2012 03:56 PM, Corinna Vinschen wrote:
> >> As long as it's consistent with coreutils I'll certainly do the change.
> >
> >Thanks! Would you mind to CC the cygwin list when the next upstream
> >sed release is available?
>
> Sure, it should be real
On 02/13/2012 03:56 PM, Corinna Vinschen wrote:
> As long as it's consistent with coreutils I'll certainly do the change.
Thanks! Would you mind to CC the cygwin list when the next upstream
sed release is available?
Sure, it should be real soon now since a new release has been long overdue.
[Sent again. I missed all the CC's in my previous reply. Sorry!]
On Feb 13 15:37, Paolo Bonzini wrote:
> On 02/13/2012 03:12 PM, Eric Blake wrote:
> >But fixing this should be done upstream, and not in cygwin.
>
> As long as it's consistent with coreutils I'll certainly do the change.
>
> Paol
On Feb 13 15:37, Paolo Bonzini wrote:
> On 02/13/2012 03:12 PM, Eric Blake wrote:
> >But fixing this should be done upstream, and not in cygwin.
>
> As long as it's consistent with coreutils I'll certainly do the change.
>
> Paolo
Thanks! Would you mind to CC the cygwin list when the next upstr
From: Earnie Boyd
>On Sat, Feb 11, 2012 at 12:56 PM, Corinna Vinschen wrote:>
>> That's why I wrote "on systems supporting this mode". Sed input is
>> text input in the first place. Therefore it's using textmode in the
>> first place. This is done so for a long time. If it's not what you
>> nee
On 02/13/2012 03:12 PM, Eric Blake wrote:
But fixing this should be done upstream, and not in cygwin.
As long as it's consistent with coreutils I'll certainly do the change.
Paolo
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documenta
On Mon, Feb 13, 2012 at 9:12 AM, Eric Blake wrote:
>
> Personally, I think it is a bug that upstream sed is using 't' in
> fopen() in the first place. Linux does NOT have an 'rt' mode for a
> reason: 't' is non-standard. On cygwin, the preference used in
> coreutils is that you get text mode by u
[adding bug-sed - see this thread in cygwin:
http://cygwin.com/ml/cygwin/2012-02/msg00313.html]
On 02/11/2012 10:19 AM, Earnie Boyd wrote:
>>> By this I assume you to mean that the -b option opens the input file
>>> in binary mode. But the mount table the OP showed was already in
>>> binary mode.
On Sat, Feb 11, 2012 at 12:56 PM, Corinna Vinschen wrote:
> That's why I wrote "on systems supporting this mode". Sed input is
> text input in the first place. Therefore it's using textmode in the
> first place. This is done so for a long time. If it's not what you
> need, there's a workaround,
On Feb 11 12:19, Earnie Boyd wrote:
> On Sat, Feb 11, 2012 at 5:06 AM, Corinna Vinschen wrote:
> > On Feb 10 14:44, Earnie Boyd wrote:
> >> On Fri, Feb 10, 2012 at 10:07 AM, Corinna Vinschen wrote:
> >> > On Feb 10 08:02, Nellis, Kenneth wrote:
> >> >> Cygwin 'sed' seems to be stripping CRs from it
On Sat, Feb 11, 2012 at 5:06 AM, Corinna Vinschen wrote:
> On Feb 10 14:44, Earnie Boyd wrote:
>> On Fri, Feb 10, 2012 at 10:07 AM, Corinna Vinschen wrote:
>> > On Feb 10 08:02, Nellis, Kenneth wrote:
>> >> Cygwin 'sed' seems to be stripping CRs from its input.
>> >> Linux sed doesn't do this. Exam
On Feb 10 14:44, Earnie Boyd wrote:
> On Fri, Feb 10, 2012 at 10:07 AM, Corinna Vinschen wrote:
> > On Feb 10 08:02, Nellis, Kenneth wrote:
> >> Cygwin 'sed' seems to be stripping CRs from its input.
> >> Linux sed doesn't do this. Example:
> >
> > Try the -b option.
>
> By this I assume you to me
On Fri, Feb 10, 2012 at 10:07 AM, Corinna Vinschen wrote:
> On Feb 10 08:02, Nellis, Kenneth wrote:
>> Cygwin 'sed' seems to be stripping CRs from its input.
>> Linux sed doesn't do this. Example:
>
> Try the -b option.
By this I assume you to mean that the -b option opens the input file
in binary
From: Corinna Vinschen
> On Feb 10 08:02, Nellis, Kenneth wrote:
> > Cygwin 'sed' seems to be stripping CRs from its input.
> > Linux sed doesn't do this. Example:
>
> Try the -b option.
Thanx for that. It's not a problem for me. I was just
reporting what looks like a Cygwin bug in case someo
On Feb 10 08:02, Nellis, Kenneth wrote:
> Cygwin 'sed' seems to be stripping CRs from its input.
> Linux sed doesn't do this. Example:
Try the -b option.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT
On Aug 9 16:41, Carles Cufi wrote:
> Hi there,
>
> I just found out in the IRC channel that to avoid trouble with
> cygwin's sed turning \r\n into \n one needs to pass the "--binary"
> flag. But this is not documented in the sed man pages, I was wondering
> if it should be.
I think this is an up
On Thursday, May 20, 2010, Thomas Wolff:
> With LANG=anything-unknown, the charmap is set to ASCII, so it works (as
> there is at least no multibyte character then).
Anything above 0x7F is invalid with charset ASCII though (since
1.7.2). But perhaps sed skips the multibyte conversion functions wh
Am 20.05.2010 18:05, schrieb Andy Koppe:
On Thursday, May 20, 2010, Jurriaan wrote:
A very long sed script that's been working for ages (back from the 1.5
age) here has stopped working.
It turned out sed doesn't like some strings anymore when environment
variable LANG is empty. With LANG=AS
On Thursday, May 20, 2010, Jurriaan wrote:
> A very long sed script that's been working for ages (back from the 1.5
> age) here has stopped working.
>
> It turned out sed doesn't like some strings anymore when environment
> variable LANG is empty. With LANG=ASCII, there are no problems.
>
> The act
> A very long sed script that's been working for ages (back from the 1.5
> age) here has stopped working.
>
> It turned out sed doesn't like some strings anymore when environment
> variable LANG is empty. With LANG=ASCII, there are no problems.
>
> sed -e"s/@a/ a/g;"
>
> where a is character 0xe
Michael Moser wrote:
-Original Message-
Ooops - apologies! Thought I routinely did so, but must have
overlooked
it this time.
FYI, you did it above too. None of the above information
belongs in the body of your message.
What - you get someone's email addresses there? Very odd: I
> -Original Message-
> >
> >Ooops - apologies! Thought I routinely did so, but must have
> overlooked
> >it this time.
>
> FYI, you did it above too. None of the above information
> belongs in the body of your message.
What - you get someone's email addresses there? Very odd: I swear
On Mon, Mar 30, 2009 at 11:20:00PM +0200, Michael Moser wrote:
>
>> -Original Message-
>> From:
>> [mailto:
>> Sent:
>> To:
>> Subject:
>>
>> BTW please trim the redundant headers... it's really
>> considerate not to post people's email addresses in the body
>> of your post because if
> -Original Message-
> From: cygwin-ow...@cygwin.com
> [mailto:cygwin-ow...@cygwin.com] On Behalf Of Dave Korn
> Sent: Montag, 30. März 2009 23:02
> To: cygwin@cygwin.com
> Subject: Re: sed converts 8-bit input text to 16-bit
> (Unicode-16?) characters - how to supp
Michael Moser wrote:
>
>> -Original Message-
BTW please trim the redundant headers... it's really considerate not to post
people's email addresses in the body of your post because if you do so they
get harvested by spammers.
>> I tried with input files
>> containing german umlauts and
> From: michael.mo...@sunrise.ch
> To: cygwin@cygwin.com
> Subject: RE: sed converts 8-bit input text to 16-bit (Unicode-16?) characters
> - how to suppress that?
> Date: Mon, 30 Mar 2009 17:56:58 +0200
>
>
>> -Original M
> -Original Message-
> From: cygwin-ow...@cygwin.com
> [mailto:cygwin-ow...@cygwin.com] On Behalf Of Dave Korn
> Sent: Montag, 30. März 2009 14:46
> To: cygwin@cygwin.com
> Subject: Re: sed converts 8-bit input text to 16-bit
> (Unicode-16?) characters -
> -Original Message-
> From: cygwin-ow...@cygwin.com
> [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen
> Sent: Montag, 30. März 2009 14:11
> To: cygwin@cygwin.com
> Subject: Re: sed converts 8-bit input text to 16-bit
> (Unicode-16?) characters -
> Date: Mon, 30 Mar 2009 14:10:43 +0200
> From: corinna-cyg...@cygwin.com
> To: cygwin@cygwin.com
> Subject: Re: sed converts 8-bit input text to 16-bit (Unicode-16?) characters
> - how to suppress that?
>
> On Mar 30 13:48, Mich
Corinna Vinschen wrote:
> On Mar 30 13:48, Michael Moser wrote:
>> I need to mangle a file containing "8-bit ASCII" characters (i.e. the
>> file contains also characters in the upper 8-bit range, namely a few
>> umlauts as well as some french accented characters).
>>
>> Strange enough, the SED ver
On Mar 30 13:48, Michael Moser wrote:
> I need to mangle a file containing "8-bit ASCII" characters (i.e. the
> file contains also characters in the upper 8-bit range, namely a few
> umlauts as well as some french accented characters).
>
> Strange enough, the SED version that came as part of cygw
On Tue, 27 Jun 2006, Dave Kilroy wrote:
On 6/27/06, David Mastronarde wrote:
On Sun, 25 Jun 2006, Dave wrote:
> David Mastronarde wrote:
>> After upgrading sed from 4.1.4 to 4.1.5, I found that line endings were
>> being converted from CRLF to CRCRLF when the input file was specified
>> with
On 6/27/06, David Mastronarde wrote:
On Sun, 25 Jun 2006, Dave wrote:
> David Mastronarde wrote:
>> After upgrading sed from 4.1.4 to 4.1.5, I found that line endings were
>> being converted from CRLF to CRCRLF when the input file was specified
>> with a windows file path:
>>
>> % sed -e 's/g5a/s
On Sun, 25 Jun 2006, Dave wrote:
David Mastronarde wrote:
After upgrading sed from 4.1.4 to 4.1.5, I found that line endings were
being converted from CRLF to CRCRLF when the input file was specified
with a windows file path:
% sed -e 's/g5a/setname/g' < 'c:\cygwin\home\mast/sedtestin' > ! s
David Mastronarde wrote:
After upgrading sed from 4.1.4 to 4.1.5, I found that line endings were
being converted from CRLF to CRCRLF when the input file was specified
with a windows file path:
% sed -e 's/g5a/setname/g' < 'c:\cygwin\home\mast/sedtestin' > ! sedtestout
Converting the path to cyg
, Charles
Cc: cygwin@cygwin.com
Subject: RE: sed: 4.1.5 breaks libtool generation
<http://cygwin.com/acronyms/#TOFU> reformatted.
On Wed, 21 Jun 2006, Stepp, Charles wrote:
> -Original Message-
> From: Christopher Faylor
[mailto:[EMAIL PROTECTED]
> Sent: Saturday, June 17, 2
YMTNQREAIYR>. Thanks.
> Subject: Re: sed: 4.1.5 breaks libtool generation
>
> > On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote:
> > >Given the fact that cygwin runs on a machine where the native linend
> > >is CRLF, having a major component not recog
It is?
-Original Message-
From: Christopher Faylor
[mailto:[EMAIL PROTECTED]
Sent: Saturday, June 17, 2006 12:30 AM
To: cygwin@cygwin.com
Subject: Re: sed: 4.1.5 breaks libtool generation
On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote:
>Given the fact that cygwin runs
Just sending the OPs reply so that it is in the mailing list archive.
Mark Hessling wrote:
Mark Hessling wrote:
Actually, what you describe is clear enough, but since CRLF handling
isn't done by the Linux version of sed either, you would have the same
problem on Linux. The question here is how
Mark Hessling wrote:
Actually, what you describe is clear enough, but since CRLF handling
isn't done by the Linux version of sed either, you would have the same
problem on Linux. The question here is how did this file get created
with CRLF in the first place?
I have several cross-platform proj
Original message
>Date: Sat, 17 Jun 2006 00:30:05 -0400
>From: Christopher Faylor <[EMAIL PROTECTED]>
>Subject: Re: sed: 4.1.5 breaks libtool generation
>To: cygwin@cygwin.com
>
>On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote:
>>Given
On Sat, Jun 17, 2006 at 02:24:00PM +1000, Mark Hessling wrote:
>Given the fact that cygwin runs on a machine where the native linend is
>CRLF, having a major component not recognise CRLF as a linend when
>handling text files is, AFAIAC, a major problem.
...unless you stop to consider that sed is s
I've just found the above titled thread; the problem I am also encountering.
>Actually, what you describe is clear enough, but since CRLF handling
>isn't done by the Linux version of sed either, you would have the same
>problem on Linux. The question here is how did this file get created
>with CR
Corinna Vinschen writes:
> Actually, what you describe is clear enough, but since CRLF handling
> isn't done by the Linux version of sed either, you would have the same
> problem on Linux.
Sure, no argument here. My goal wasn't to prove that Cygwin's sed is doing
something wrong, but rather to c
On Feb 25 04:19, Wlodek Szafran wrote:
> Corinna Vinschen cygwin.com> writes:
>
> > sed's internal getline enforces CRLF line ending recognition regardless
> > of the mount type, which results in mishandling of binary input files.
> > sed has no -b/--binary option. So by using newlib's getline w
Corinna Vinschen cygwin.com> writes:
> sed's internal getline enforces CRLF line ending recognition regardless
> of the mount type, which results in mishandling of binary input files.
> sed has no -b/--binary option. So by using newlib's getline which
> doesn't enforce CRLF->LF conversion, sed 4
On Feb 24 12:08, Pavel Holejsovsky wrote:
> Corinna Vinschen wrote:
> >On Feb 24 04:01, Charles Wilson wrote:
> >>Yaakov S (Cygwin Ports) wrote:
> >>>-BEGIN PGP SIGNED MESSAGE-
> >>>Hash: SHA1
> >>>
> >>>After a recent update to my Cygwin installation, suddenly
> >>>configure-generated libt
Pavel Holejsovsky wrote:
One incompatibility of 4.1.5 is that sed no longer works correctly with
CRLF-style files on binary mounts. For example, 's/^$//' script no
longer filters out empty lines if they are CRLF terminated, but works OK
for LF terminated lines. However, I'm not sure whether t
Corinna Vinschen wrote:
On Feb 24 04:01, Charles Wilson wrote:
Yaakov S (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After a recent update to my Cygwin installation, suddenly
configure-generated libtool scripts give me this error when compiling
and linking C++ code:
lib
On Feb 24 04:01, Charles Wilson wrote:
> Yaakov S (Cygwin Ports) wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >After a recent update to my Cygwin installation, suddenly
> >configure-generated libtool scripts give me this error when compiling
> >and linking C++ code:
> >
> >libto
Yaakov S (Cygwin Ports) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After a recent update to my Cygwin installation, suddenly
configure-generated libtool scripts give me this error when compiling
and linking C++ code:
libtool: ignoring unknown tag CXX
And even worse, it tries to use g
On Feb 4 19:58, Rokas Masiulis wrote:
> Hi,
>
> i can't force to work sed in true binary mode:
>
> this is test case:
>
> $ echo -en '\r\n' | sed -e '' | od -t x1
> 000 0a
> 001
>
> but expected result is:
> $ echo -en '\r\n' | od -t x1
> 000 0d 0a
> 002
I've uploaded a new se
Hhmm...Good point. I betcha it's the slashes
$ echo $APP_SERVER_DOMAIN
C:/bea/user_projects/domains/fimdomain
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Peter Rehley
Sent: Thursday, October 06, 2005 2:28 PM
To: Cygwin List'
Subjec
quot;_User_email = "$cur_email"/"$system"_User_email =
"$new_mail"/" $file > ./tmp.txt
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Peter Rehley
Sent: Thursday, October 06, 2005 1:41 PM
To: Cygwin List'
Subjec
1 - 100 of 133 matches
Mail list logo
