Re: reading a file into an array. mapfile? (f)?

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2008-09-19 at 10:44 -0400, Rocky Bernstein wrote:
> 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.

Mod-time you get from zsh/stat.

You probably want to avoid loading the 'stat' built-in name, since
nowadays that's an external command with different behaviour, but:
 zmodload -aF zsh/stat b:zstat
will get you 'zstat', same behaviour.

% zstat -H foo src
% print ${(k)foo}
blksize nlink size rdev mode mtime inode blocks device atime uid link ctime gid
% print $foo[mtime]
1220980489
% zstat -sH foo src
% print $foo[mtime]
Tue Sep  9 10:14:49

Cryptographic, I'm more cautious of, as the cryptographic libraries tend
to be fairly large and the ABI compatibility awkward.  Having an
external command seg-fault because the version of OpenSSL it's loading
doesn't match the version it was linked against is one thing.  Having
your shell seg-fault and die when a module is loaded or you run a
command is another.

While zsh could just implement certain checksum algorithms internally,
picking which ones are "safe" is a cryptanalysis job and the sort of
thing we should stay away from, as the decisions made would last for
years (measured in decades, probably).

IMO adding cryptographic support to the shell would be into the area of
bloat; zsh is still a Unix shell and still well suited to running
external commands.

Is there a reason that a single fork/exec to get a checksum is a problem
(besides worrying about the portability of the checksum commands used)?

-Phil