On Sat, Sep 20, 2008 at 4:29 PM, Phil Pennock
<zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
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
Ok. Thanks! Missed seeing this because it's not mentioned the last installed manpage for zshmodules that I have. (However I do see it now in Doc/Zsh/mod/mod_stat.yo
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.
Actually I didn't use the word "Cryptographic" initially; someone else did. And I put it in quotes. I'm more thinking hash of the file data more like a signature or checksum.
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).
I think you're making this a bigger deal than it need be. A module implementing SHA1 would probably be sufficient although what implementers I think tend to find is that if you code SHA1 adding others isn't a big deal. So Perl, Python and Ruby all have such modules for SHA1 along with and for a vast number of other kinds of digests.
IMO adding cryptographic support to the shell would be into the area of
bloat;
Perhaps. All of this is a matter of taste and opinion. To me it's as much bloat as say mod_files given that, as you say zsh is still well-suited to running external commands. :-) If it's put in a module, folks can decide to install it or not.
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)?
Portability is what exactly what I was thinking.
Here is the particular scenario I'm thinking. In debuggers for C, C++, Java, Python and Ruby (among probably others) one can debug a program remotely. What often happens here is that the source code may be coming from a different filesystem than where the program is in fact running. In this situation one would like a signature or checksum of the data to verify that the source code is the same. I've noticed in the past that "sum" on Solaris gives a different result than "sum" on GNU/Linux. I think however that "md5sum" does give the same result.
But in practice, I am not aware of any debugging systems make use of a checksum of the source currently. Kind of a shame, but that's the way it is. And in truth I can't see zshdb getting good enough in the short term to need this anytime soon. And if I really needed it, I could code up a zsh module.
I had just thought that if it happens to be out there -- like fast file reading into an array or getting the modification time -- I'd use it in preparation for someday when it really could be used.
Although the example I give is drawn from debuggers, the same is true in other problem domains. git for example makes use of signatures for files. And again the data doesn't have to reside strictly in a file, it could be an internal string.
But again, thanks for the info.
-Phil