Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"

[Linda Walsh]

Andreas Schwab wrote:
> Linda Walsh <bash@tlinx.org> writes:
>
> >         Except that in-line HERE docs don't need to be implemented
> > through a tmp file unless you want to slow things down.
> >         They should be read out of memory and NOT transfered to
> > to non-existent, external storage.
>
> You need a file descriptor for your memory storage.
---
Why?

If it is the case that you can't rely on OS services, you are
saying you can't access memory or create a virtual descriptor
that reads out of a large malloc'ed buffer?

Both C++ and Perl have routines to do I/O on strings directly
that don't go through system file descriptors to do it.

Last I checked, 'C' was a common denominator for both as well
as Bash.  So why should it be the case that Bash can't do it when
it is the primary system shell available at boot.

I wrote my own line-splitting, word splitting and buffering code
to avoid libc buffering to talk to files in "proc", repeatedly
w/o closing & reopening.  It's mostly in C and was relatively
simple compared to the work of writing a simple scheduler.

There's no reason for me to expect that a system shell wouldn't
have such available.