== 11/11/07, Herbert Xu ==
> On Tue, Oct 30, 2007 at 04:23:35AM +0000, Oleg Verych wrote:
> >
> > } 8<<""
> > ======================
>
> Actually this (the empty delim) only works with dash by accident.
> I've tried bash and pdksh and they both terminate on the first
> empty line which is what you would expect rather than EOF. The
> real Korn shell does something completely different.
>
> I've fixed this in dash to conform to bash/pdksh.
[]
> > Placing binary stuff safely with optimized reading/writing by big
> > blocks without parsing, if delimiter is "", are things, that i'd like
> > to propose and possibly fix/implement soon.
>
> Sorry but I can't see how we can get this to work in a meaningful
> way.
I hope you know what `makeself` is. There is to much scripting and
external tools used to achieve basic thing: to copying binary data after
script in the script file to a separate file and to do something with it
(mainly gunzip/bunzip + run another script). Also it all is written is
quoted form, which is very unreadable and ugly.
After making that very simple shell stub (in prev mail), i realized, that
things can be done very easily.
1) here-doc data is started after first new line of the command, that
has `<<' syntax.
There are may be multiple chunks, but let's concentrate on that with
empty delimiter.
2) As stated in shell description "2.3 Token Recognition", there are
two major modes, here-doc and not. It is described, that quoted
delimiter yields whole here-data to be a word, that ends with a
*line*, consisting with delimiter and `\n'.
This means `\n\n', if delimiter is `""'.
But what is special about `""'? It is, that there is no intention from
the user to limit data, isn't it? Even `\n\n' is just a side effect of
the written standard.
So, what i propose is basically:
here_doc() {
if delim = ""
then
io_setup()
if fork_shell()
then
while ! ( eof || fatal_error )
do read in
write out
done
exit
fi
io_reset()
return error
fi
# other delim handling
....
}
I.e. just a plain copy of data, thus no problems with `\0' or any other
parsing/memory management. I don't know even if the Linux VFS can strip
head of the file, thus preventing stupid copying.
(Linux, because it doesn't seem a problem to configure and implement
kernel-dependent features, so many fancy kernel developers spending much
more time designing, testing and applying into the kernel mainline.)
#--
{ dd bs=65536 0<&8 1>"$F" 8<&- 2>&-
exec 8<&-
chmod u+x "$F"
echo 1>&2 "Running binary \`$F'...
"
(exec "$F")
} 8<<''
#!/usr/bin/printf $$Running from file: %s\n
not used and ran
#--
How `<<-' was described, i see no problem what so ever to implement this
very simple idea. What is/was so special about leading tabs in 70s-80s?
Why useful, small and fast functionality must be prevented just because
it's "not like historical shell was"?
==
OTOH, fixing dash to prevent binary data from being parsed and broken is
another issue. (2) says, that there's second mode of handling input, and
that input supposedly not a text (i.e. without `\0'). Dash seem to apply
same "tokenization" even for here-doc with quoted delimiter.
BTW, "ash silently discards null characters" the original ash man page
states.
____
-
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
