RFE: please add "hash-type" prefix to *sum utilities

[Dmitry Yu. Bolkhovityanov]

	All of /usr/bin/*sum utilities produce very similar output 
consisting of a long number of hex-digits, so that later one can't 
instantly understand what type of hash it is.


	It was acceptable in the old md5sum-only days, but now it causes 
much confusion. For example, see RedHat bug #515715.


	Of course, one can count the number of digits, but a) that's 
weird; b) different algorythms can use equal hash length.


	The problem would be eliminated if *sum utils could prefix hashes 
with "type-tag", similarly to what is done in /etc/shadow.  For example, 
"sha1:..." or "sha1/...".
(And that is THE RIGHT THING -- data of unknown type is bad, so http 
introduced "Content-type:" header, PGP includes "Hash:" prefix, etc.  With 
current diversity of hash types, that becomes the barest necessity for 
*sum utils too...)


(Of curse, for compatibility reasons, that have to be switched on 
explicitly -- e.g., with "-l" (Label). And besides adding such tags, *sum 
have to understand such prefixes, but that's trivial.)


_
  Dmitry Yu. Bolkhovityanov
  The Budker Institute of Nuclear Physics
  Novosibirsk, Russia

su.1, hostname.1, and arch.1 missing in tarball

[Alfred M. Szmidt]

Any program listed in --enable-no-install-program won't get its man
pages generated during dist/distcheck, so currently to install those
man pages on needs have perl installed to be able to run help2man.

Not sure what the best way is to fix this, thoughts?

Re: diskscrub and shred

[Jim Garlick]

On Fri, Nov 27, 2009 at 03:24:12PM +0100, Jim Meyering wrote:
> Toni Ruottu wrote:
> > I've been trying to get Diskscrub (
> > http://*code.google.com/p/diskscrub/ ) to Ubuntu installation cd.
> > Having it on the cd would be good as it'd allow one to boot from the
> > cd and securely erase the entire hard disk.
> >
> > Usually getting a package to the cd is done in three steps:
> >   1) get the software packaged
> >   2) apply for official support from Canonical
> >   3) prove that including the package on the cd is a good idea
> >
> > The software just got packaged and was included into Ubuntu universe,
> > and obviously having such a tool on the cd is a good idea. So I got
> > two of three covered. However it turned out that GNU Coreutils package
> > contains a similar too called shred. Adding another tool with the same
> > purpose was considered bad, as it would complicate things. Also a wide
> > range of other systems ship with Coreutils preinstalled, so having a
> > proper tool as part of the Coreutils is desired.
> >
> > It was decided that instead of adding yet another tool, we should try
> > to get the developers behind the said tools to co-operate, and get all
> > the useful features from Diskscrub merged into shred where they will
> > be useful for a larger user community. So here I am delivering the
> > message to whom I believe to be the lead behind the two projects.
> 
> Sounds like a fine project.
> Now all we need is someone willing to compare features and to
> present the results.  Maybe someone will even propose a patch or two.

Sorry for the delay responding - I was out on holiday last week.

I think the main thing shred needs is the more modern 3-4 pass overwrite
algorithms.  Supposedly the full Gutmann algorithm is really only effective
on MFM drives, and 3-4 passes is all you need on modern drives.  As Toni
points out, it would be extremely advantageous to have this installed on
every machine that runs coreutils.

I could prepare a patch to coreutils to make various overwrite patterns
including Gutmann selectable via shred option and a NNSA NAPS-14.1-C
compliant pattern the default (random, random, 0x00, verify).  This would
make my employer happy.  Would such as patch be considered, Jim M.?

Jim

Bug in test

[Florian Lehmann]

Dear Developers,

I recently recognised a missfunktion in coreutil test. When calling test 
with option --help, test does not print anything and returns with 
exit-code 0.


I'm running test on the latest Ubuntu GNU Linux.

With best regards from Ulm/Germany,
Florian Lehmann

Re: Bug in test

[Bob Proulx]

Florian Lehmann wrote:
> I recently recognised a missfunktion in coreutil test. When calling test  
> with option --help, test does not print anything and returns with  
> exit-code 0.

Thanks for your report.  But what you are seeing is not a bug in test
but is instead simply a misunderstanding of how it is used.  The
'test' behavior has been around for decades and the use is
standardized upon previously existing behavior.

Two points are of interest about your test --help question.  One is
that unless you are careful you are getting the shell builtin test and
not the external standalone test program.

  $ type test
  test is a shell builtin

Two and the main point of your issue is that test is required to
evaluate the expression very specifically based upon the total number
of arguments.  Since your case "test --help" provides only one
argument then test is required to "Exit true (0) if $1 is not null;
otherwise, exit false."  Since "--help" is not null then test will
exit true (0) for that expression.

See the standards page for more information.

  http://www.opengroup.org/onlinepubs/009695399/utilities/test.html

Bob

Re: Bug in test

[Eric Blake]

Bob Proulx  proulx.com> writes:

> Two points are of interest about your test --help question.  One is
> that unless you are careful you are getting the shell builtin test and
> not the external standalone test program.

In addition to Bob's excellent points, there is one more thing to consider: the 
alternate spelling of test DOES support the --help option.  Given that your 
system is Ubuntu, you can probably do:

/bin/[ --help

to see the help output corresponding to coreutils' test.

-- 
Eric Blake

Re: diskscrub and shred

[Pádraig Brady]

Jim Garlick wrote:
> I think the main thing shred needs is the more modern 3-4 pass overwrite
> algorithms.  Supposedly the full Gutmann algorithm is really only effective
> on MFM drives, and 3-4 passes is all you need on modern drives.  As Toni
> points out, it would be extremely advantageous to have this installed on
> every machine that runs coreutils.

Note since coreutils-7.1 shred has defaulted to 3 random passes:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=83ae1bdd

> I could prepare a patch to coreutils to make various overwrite patterns
> including Gutmann selectable via shred option and a NNSA NAPS-14.1-C
> compliant pattern the default (random, random, 0x00, verify).  This would
> make my employer happy.  Would such as patch be considered, Jim M.?

The verify step you mention, would address the TODO in the commit above.

cheers,
Pádraig.

rm 8.1

[Ladislav Hagara]

Hi all,

the behaviour of rm from last stable coreutils 8.1 is quite different
from previous 7.6 one.
When using new rm lots of strange message appear: rm: invalid argument:
`', for example when run make in libxt sources.
Moreover some scrips which until now have removed files don't work with
new rm.

Example:

Previous rm prints message "No such file or directory" and removes files:

$ rm --version | head -n 1
rm (GNU coreutils) 7.6
$ touch a b c; rm a b "" c; ls
rm: cannot remove `': No such file or directory
$

New 8.1 rm prints another message "invalid argument" and DOESN'T remove
files:

# rm --version | head -n 1
rm (GNU coreutils) 8.1
# touch a b c; rm a b "" c; ls
rm: invalid argument: `'
a  b  c
#

This problem arises when variable isn't defined, for example rm "$FILE".

Is this a bug or a new feature of rm 8.1?
Should all scripts be rewritten (test if file really exist and then
remove it) or new rm 8.2 will again remove files?

Thanks.

-- 
Ladislav Hagara
http://www.sourcemage.org/

Re: rm 8.1

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ladislav Hagara on 11/30/2009 4:46 PM:
> New 8.1 rm prints another message "invalid argument" and DOESN'T remove
> files:
> 
> # rm --version | head -n 1
> rm (GNU coreutils) 8.1
> # touch a b c; rm a b "" c; ls
> rm: invalid argument: `'
> a  b  c
> Is this a bug or a new feature of rm 8.1?

Thanks for the report.  This is indeed a regression and a violation of
POSIX, and was probably caused by our move from a hand-rolled recursion
over to using an enhanced fts interface (hence I'm guessing it popped up
in coreutils 8.0).  It will be fixed before the next release.

> Should all scripts be rewritten (test if file really exist and then
> remove it) or new rm 8.2 will again remove files?

It depends on how worried you are about the likelihood of distros
distributing unpatched coreutils 8.0 and 8.1 builds, and how worried you
are about encountering it in the wild.  In general, passing an empty file
name to rm is never going to succeed, so there's already room for
improvement in your scripts; so this could be the justification to make
those changes.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksUcZoACgkQ84KuGfSFAYCC7wCeJeU8LknVE8btEKWguOyc20K9
V2YAnRNZwGqyG1yWAziRHOOn4aAd7DBD
=BUaH
-END PGP SIGNATURE-

[bug #28141] REQ: df and du, use -g to specify a 1gig block size

[anonymous]

URL:
  

 Summary: REQ: df and du, use -g to specify a 1gig block size
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Tue 01 Dec 2009 05:27:07 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The initial legwork has been done, from the mailing list of "Fri, 5 Dec
2008".  Other implementations use -g for 2's based 1GB block size, but
coreutils apparently hasn't yet.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: Bug in test

[Bob Proulx]

Please take care to make sure the mailing list is included in your
reply so that others may share in the discussion.  You can do this by
using the reply-to-mailing-list function.  Or lacking that use
reply-to-all.

> thanks for your reply, I see your point. In this case, the manpage seems  
> to bee irritating: (Qutoing from the manpage)

> SYNOPSIS

The synopsis is the part that shows how it works.

>   test EXPRESSION
>   test

Neither of those show any options.  So 'test' does not handle any
options.

>   [ EXPRESSION ]
>   [ ]
>   [ OPTION

The last shows the OPTION listing.  So (as Eric noted in his
follow-up) only the '[' command can take options.  But it is also a
shell builtin.  So you must avoid the shell's version and call out the
external one explicitly.

  /usr/bin/[ --version

  /usr/bin/[ --help

Since both 'test' and '[' are shell builtins it is unusual to ever
actually use the external ones.  Most of the time the shell builtin
versions will be used.  That is the desirable case since it is so much
faster than launching the external command.  The external ones are
provided so that a program (such as a C program) can exec(2) them.  If
they were only shell builtins then an exec(2) of them would fail.  And
originally they were external standalone programs so removing them
would have been a regression, some decades ago.

Bob


Florian Lehmann wrote:
> Hi Bob,
>
> thanks for your reply, I see your point. In this case, the manpage seems  
> to bee irritating: (Qutoing from the manpage)
>
> TEST(1)  User Commands  
> TEST(1)
>
> NAME
>   test - check file types and compare values
>
> SYNOPSIS
>   test EXPRESSION
>   test
>
>   [ EXPRESSION ]
>   [ ]
>   [ OPTION
>
> DESCRIPTION
>   Exit with the status determined by EXPRESSION.
>
>   --help display this help and exit
>
>   --version
>  output version information and exit
>
> In which case is test supposed to display the help when called with the   
> option --help?
>
> Best regards,
> Florian Lehmann