bug#26879: end-of-line issue with cygwin 4.4-1 sed 4.4

[Dick Dunbar]

To round out this discussion:
I wanted a simple filter to ensure filename paths didn't contain spaces.

For example:
  find /foo -maxdepth 1 -atime +366 -print0 |
     xargs -0 sh -c 'mv "$@" /archive' move

So why are there different flags to indicate null-terminated lines?
  find -print0
  xargs -0
  sed  -z

Seems silly.  To make a non-breaking-code-change,
why not add "-z" to the find and xargs command so they are compatible?

And ... because we're dealing with the same issue of executables
creating stream data, why doesn't sed/awk/grep have an option
to deal with null delimited lines such that "$" would find them.

Or will it just work ... as my example of echoing $fn does where
sed finds the end-of-line ( by length, or because no more ascii chars ).

Having sed recognize \r, \n, \0 as end of line might cause some
breakage if you have to deal with data that has embedded nulls.
So it might require a sed flag ( -r0 ) to signal intent.

Had to check:
find . -type f -print0 | sed -e "s/^/'/" -e "s/\$/'/"

Doesn't work.  One very long string of null terminated filenames is
returned.

So we now know that sed does not check for \0 as a line terminator.
And the sed -z flag produces the same long string.

find . -type f -print0 | sed -z -e "s/^/'/" -e "s/\$/'/"






On Thu, May 11, 2017 at 3:07 PM, Dick Dunbar <address@hidden> wrote:

>
> On Thu, May 11, 2017 at 2:59 PM, Assaf Gordon <address@hidden>
> wrote:
>
>>
>> What does "Windows Subsystem For Linux" do with line-endings?
>
>
>
> It is a linux kernel, ported to native Windows api's.
>
> I had it installed briefly, but threw it out because they required you
> to turn off UAC globally for the machine.   It's beta.
> They'll eventually figure out how to make bash operate like a real
> windows trusted executable.  I have cygwin;  I can wait.
>