Thanks, Bart and Peter - this works great! I will note and make use of the fact that the lack of a null line at the end means the file doesn't have a final newline.
So now with this, file listing (the "list" command) is now in the debugger. Down the line, file information should be kept. Most important would be modification time and some sort of checksum (or "cryptographic") information. Too bad this isn't already in the zsh/files module.
(And it would be cool and I think relatively straightforward to add a Ruby-like SCRIPT_LINES__ capability. In the context of a debugger or any profiling/introspection tool it means that one reliably has the lines of the script under inspection.)
On Fri, Sep 19, 2008 at 7:00 AM, Peter Stephenson
<pws@xxxxxxx> wrote:
"Rocky Bernstein" wrote:
> Further tests show that the behavior seems to be to drop blank lines but put
> one at the end of the file.
Apologies, you're right; it seems you *do* need the @ flag, but my test
was too simple to show it.
array=("${(f@)mapfile[foo.txt]}")
I'm not entirely sure why that is but I must be misremembering the (f)
rules.
Also, it seems you always get an extra blank at the end: I think that's
because mapfile returns the complete file including the "\n" and the (f)
flag splits on that "\n" giving you a blank after it. This should be
entirely predictable, however (I hope): you get that last blank line if
there was a final newline, and if you don't get it there wasn't a final
newline.
I think that's the one difference from "${(f@)$(<foo.txt)}": in that
case a final newline is always stripped, but consequently you can't tell
if there was one there.
--
Peter Stephenson <
pws@xxxxxxx> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070