Andreas Schwab wrote:
Linda Walsh <b...@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.
