Current stable version of coreutils (6.9) has 8(!) utilities
which somehow compute or/and check a message digest. They are:
'md5sum', 'sha1sum', 'sha224sum', 'sha256sum', 'sha384sum',
'sha512sum' and finally 'sum' and 'cksum'. It's already a little
bit confusing and it seems
Oh, definitely 'confusing' was a wrong word. It's all about style...
Let me explain that in different way.
Let's imagine I knew nothing about 'coreutils' and I was looking for
something that can sort text files. I'd just try to type 'sort --help'
or more likely 'man sort'. It's logical and it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Alfred M. Szmidt on 4/9/2007 5:13 AM:
I don't see any major problem why something like `hashsum ALGORITHM'
wouldn't work though, `md5sum' could be the same as `hashsum md5'.
And then md5sum could be a shell script, or just a simple
[EMAIL PROTECTED] writes:
One more comparison. Why do we have the only one 'mknod' utility and
why don't we have separate 'bmknod' (for block devices) and 'cmknod'
(for character devices)?
mknod is just a wrapper around the syscall, which does both.
Do you fill the difference now?!
The
I don't see any major problem why something like `hashsum
ALGORITHM' wouldn't work though, `md5sum' could be the same as
`hashsum md5'. And then md5sum could be a shell script, or just
a simple program that calls `hashsum md5'.
Except that since the *sum utilities operate on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Alfred M. Szmidt on 4/9/2007 6:17 AM:
I don't see any major problem why something like `hashsum
ALGORITHM' wouldn't work though, `md5sum' could be the same as
`hashsum md5'. And then md5sum could be a shell script, or just
All 1 tests passed
==
Making check in install
make check-TESTS
PASS: trap
./basic-1:
/sw/src/fink.build/coreutils-5.96-5/coreutils-5.96/tests/install: not
writable by user `nobody'
./basic-1: skipping this test
SKIP: basic-1
PASS: create-leading
PASS: d-slashdot
Why not just: hashsum ALGORITHM [FILE]? A optional hashing
algorithm seems pointless for this.
Because on decoding, 'hashsum -c FILE' could be made smart enough
to auto-detect the algorithm based on the length of the hash, but
only if the algorithm is optional (--md5) rather than
Matt McCutchen [EMAIL PROTECTED] writes:
I would like mkdir -p to observe the default ACL in preference to the umask
(as nearly all other programs do) when creating parent directories.
Sorry, but POSIX requires that mkdir -p FOO/BAR must create FOO as
if by the following command:
mkdir -m
On Apr 9, 2007, at 2:28 PM, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Alfred M. Szmidt on 4/9/2007 6:17 AM:
I don't see any major problem why something like `hashsum
ALGORITHM' wouldn't work though, `md5sum' could be the same as
`hashsum md5'. And then
FYI, this fixes a small nit whereby ls (e.g., without -l) would
unnecessarily form and compute the length of strings like those for
owner, group, block count, etc.
ls: don't form or compute the length of strings that won't be used.
* src/ls.c (gobble_file): Form and compute length
On Mon, 9 Apr 2007, Micah Cowan wrote:
In the Ubuntu bugtracker, Malone, we've been getting several submissions of an
issue, usually phrased along the lines of cp dumps core on copy
of 4GB file to vfat (or usb), etc. See
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/75574
If
Philip Rowlands wrote:
On Mon, 9 Apr 2007, Micah Cowan wrote:
In the Ubuntu bugtracker, Malone, we've been getting several
submissions of an issue, usually phrased along the lines of cp dumps
core on copy of 4GB file to vfat (or usb), etc. See
On Mon, 9 Apr 2007, Micah Cowan wrote:
Users report having this problem when they copy to (e.g.) vfat
systems, but not ext3, so it seems to be FS-related. Even if it did
turn out to be usage limit, I would think the problem would be the
same: it's much more useful (IMO) to issue a diagnostic
Micah Cowan [EMAIL PROTECTED] wrote:
In the Ubuntu bugtracker, Malone, we've been getting several
submissions of an issue, usually phrased along the lines of cp dumps
core on copy of 4GB file to vfat (or usb), etc. See
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/75574
I'd like
Philip Rowlands wrote:
On Mon, 9 Apr 2007, Micah Cowan wrote:
Users report having this problem when they copy to (e.g.) vfat
systems, but not ext3, so it seems to be FS-related. Even if it did
turn out to be usage limit, I would think the problem would be the
same: it's much more useful
16 matches
Mail list logo
