Re: Including into the current buffer from an external source

Reply to message «Re: Including into the current buffer from an external
source»,
sent 08:58:20 22 February 2011, Tuesday
by Christian Brabandt:

> I am not sure, why you insist on NULL handling. Traditionally, shell
> scripts couldn't handle binary NULL.
In arguments only. grep, sed, awk, less, cat, cut, ... handle NULLs in files
just fine.

> The only command, I can think of, that produces NULL delimited output is
> find -print0 together with xargs -0 and even these parameters are not
> portable and in fact not even necessary.
Why it is not portable? I do not see that -print0 is claimed to be a GNU
extension in find manual.

> So handling NULL is a corner case, that you can't expect to work
> reliably anyway
You can expect to work reliably if you give up VimL. Perl, awk, python, zsh (but
not bash), ruby and many other scripting languages that I do not know about are
able to hold NULL in a string variable just like any other byte.

For VimL there is a simple rule: if command/function accepts/outputs a list of
strings (consider range of lines to be a list of strings), then each NL in each
string is NULL. That is true for edit/write/read/... as well as
readfile/writefile/getline/setline/.... If it does not accept or output a list,
then you cannot have a NULL there. Another thing is that normal-mode commands
that use registers also handle null correctly, but, for example, you cannot
distinguish NL which represents NULL and NL which represents NL if you yank
something and then parse @{register} variable in a script.

> besides, I don't see,
> how your code is "much less code" as you claimed initially.
I thought I can write it with less keystrokes. I was wrong.

Original message:
> Hi ZyX!
>
> On Mo, 21 Feb 2011, ZyX wrote:
> > > Replace ``read! echo $'\0''' with ``read!
> > > {placeholder_for_command_that_has_NULLS_in_its_output}'' and you
> > > will get `portable' example.
>
> I am not sure, why you insist on NULL handling. Traditionally, shell
> scripts couldn't handle binary NULL. They were designed to handle "text"
> files and usually required \n delimited lines (with a max line length
> around 2048 I think).
>
> The only command, I can think of, that produces NULL delimited output is
> find -print0 together with xargs -0 and even these parameters are not
> portable and in fact not even necessary. You can use "find -exec sh {}
> ... " that can handle any input without losing portability.
>
> So handling NULL is a corner case, that you can't expect to work
> reliably anyway and whether one likes system() or uses :read! is merely
> a matter of taste and shouldn't make a difference, besides, I don't see,
> how your code is "much less code" as you claimed initially.
>
> regards,
> Christian