bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26002: [patch] md5sum --digest-only


From: Michael Vogt
Subject: bug#26002: [patch] md5sum --digest-only
Date: Tue, 7 Mar 2017 09:04:02 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Mar 06, 2017 at 08:26:07PM -0800, Pádraig Brady wrote:
> On 05/03/17 23:55, Michael Vogt wrote:
[..]
> >   `md5sum /etc/papersize 2> /dev/null | awk '{print $1}'`
> >   `md5sum /etc/lsb-release | cut -d" " -f1`
> >   $(md5sum /etc/networks | sed -e 's/ .*//')
> > 
> > Having a --digest-only option in md5sum would make this a bit more
> > uniform.
> > 
> > Attached is a small patch, if the suggestion gets accepted I'm happy
> > to flesh it out more and write the man-page entry and tests.
> 
> This is one of those marginal ones, previously discussed as indicated at:
> https://www.gnu.org/software/coreutils/rejected_requests.html#checksum
[..]

Aha, thanks! I found the discussion about it now and see this was
already discussed. Sorry that I have not found in earlier.

> Note your forms above don't handle the case where a leading '\'
> is added for certain edge case filenames.
> The most general solution would be something like:
> 
>   md5sum < the_file | cut -f1 -d' '

Thanks for this. I was mostly working on this because I saw a bunch of
different ways to solve this problem. Here is another example:
    hash=$(set -- $(md5sum some-file) && echo "$1")
(and there are more).

Given that it is a common use-case I was hoping that *sum could
provide a single obvious way to do it. But I do understand that each
extra option adds maintenance burden of coreutils.

> I suppose you could avoid the new option and behave like wc.
> I.E. don't print the extraneous '-' at all.
> That would also be backwards compat with all the processing forms above.
> Though not forwards compat, in that new scripts running against
> older versions of md5sum would now not work.
> Given the minimal/obvious processing involved,
> I'm still slightly in favor for leaving as is.

For my use-case it would be a nice step forward. The scripts I deal
with usually run in the context of a given distro release. 

Cheers,
 Michael





reply via email to

[Prev in Thread] Current Thread [Next in Thread]