On Sat, Feb 18, 2006 at 07:29:53PM -0500, Daniel Hagerty wrote:
> This is supposed to be informative, not a flame war. Please don't
> assume you're being flamed; I just don't care that much about scsh.
>> And stat(). Just create a > 2GB file and try to get its size. Your
>> scsh script aborts with an error. That's the "usual caveats". It
>> keeps me from using scsh to delete files of size 0 in a directory
>> containing other (big) files. Pretty limiting.
> (delete-file "flob") where flob is in excess of 2 gigs works for
> me, as does deleting a zero length file in directories containing
> large files.
I cannot _test_ whether the file has zero size. Except by parsing the
output of (run (ls)) or something like that...
> At least on the system I'm on, rather than doing
> something semi-rational like throwing a scheme level error,
(which it does for me:
Error: 75
"Value too large for defined data type"
#{Procedure 13546 (stat-file in scsh-level-0)}
"large_file"
#t
)
> file-info:size on a large file returns a number truncated into a
> signed 32 bit quantity.
> State code that doesn't work for you rather than making english
> statements that are highly ambiguous.
(for-each (lambda (f) (if (equal? (file-size f) 0) (delete-file f)))
(directory-files))
But also
(file-exists? "large_file")
where large_file is the name of a large file. While throwing a scheme
error on (file-size "large_file") is the most reasonable thing to do
if you can't handle the number, I tend to think that from the user's
point of view, there is no good reason for "file-exists?" to
fail. (The reason is, I think, that scsh doesn't merely check for file
existence, but does a full stat() call, parsing the results and caches
them, under the assumption you are likely to ask some information on
the file next. Not unreasonable, but gives surprising results in this
case.) I actually worked around this one with
(define (file-exists? fname)
(member fname (directory-files)))
> If it was throwing a scheme error, this should be catchable by the
> normal means
Yes, I could do that, indeed.
>> I have to compile the libraries it needs as a 32 bit binary
>> first. While theoretically possible, having a distribution packaging
>> system that supports the multiple architectures supported by the
>> hardware is not there yet. (And conflicts with LSB support and that
>> kind of boring things.)
> Thinly veiled flames are not conducive to getting people to
> volunteer to help you.
Sorry you felt flamed. Wasn't my intention.
> If LSB says "thou shalt only provide 64 bit libraries to your
> users" on a mixed 32/64 arch like amd64,
It doesn't exactly say that, but its requirements for 32 bit binaries
and 64 bit binaries conflict, if I remember well. Like they both can
expect their libraries to dlopen() to be in /usr/lib/ or something
like that. Only on some 64 bit architectures. Not all of them. I don't
remember the details.
> you are doing your users a disservice by specifying the standard as
> such
You are doing one subset of users a disservice and another set of
users a service: Those that want to run binaries not specifically
prepared for your distribution, but against the standard.
> Insisting that a 64 bit flag day is a good idea doesn't seem to fly
> for a lot of people.
Yes.
--
Lionel
|