Respostas:
Você pode usar
openssl dgst -sha256 <file>
Testado no LibreSSL 2.6.4 no macOS 10.14 (Mojave).
Antes do Mojave, você pode usar openssl sha -sha256 <file>
ou openssl sha256 <file>
.
Para verificar as opções de linha de comando para o comando sha openssl: openssl sha -help
.
O OS X é enviado com um comando shasum .
> which shasum
/usr/bin/shasum
Você pode usar:
> shasum -a 256 <file>
Mais detalhes:
> shasum --help
Usage: shasum [OPTION]... [FILE]...
Print or check SHA checksums.
With no FILE, or when FILE is -, read standard input.
-a, --algorithm 1 (default), 224, 256, 384, 512, 512224, 512256
-b, --binary read in binary mode
-c, --check read SHA sums from the FILEs and check them
-t, --text read in text mode (default)
-p, --portable read in portable mode
produces same digest on Windows/Unix/Mac
-0, --01 read in BITS mode
ASCII '0' interpreted as 0-bit,
ASCII '1' interpreted as 1-bit,
all other characters ignored
The following two options are useful only when verifying checksums:
-s, --status don't output anything, status code shows success
-w, --warn warn about improperly formatted checksum lines
-h, --help display this help and exit
-v, --version output version information and exit
When verifying SHA-512/224 or SHA-512/256 checksums, indicate the
algorithm explicitly using the -a option, e.g.
shasum -a 512224 -c checksumfile
The sums are computed as described in FIPS-180-4. When checking, the
input should be a former output of this program. The default mode is to
print a line with checksum, a character indicating type (`*' for binary,
` ' for text, `?' for portable, `^' for BITS), and name for each FILE.
Report shasum bugs to mshelor@cpan.org
which shashum
não produz nada
/usr/bin
com coisas opcionais. Vou ter que verificar se esse é o caso hoje mais tarde. Atualizará a resposta se realmente vier da instalação do XCL.
shasum
retorna um hash diferente de openssl sha -sha256 <file>
(com o último sendo o hash correto). Alguma idéia do porquê?
shasum
é um script perl, usado Digest::SHA
para calcular o valor do hash. Para o mesmo arquivo, obtenho exatamente o mesmo SHA usando um shasum
ou openssl
para um SHA-256
cálculo de hash. Veja: gist.github.com/ianchesal/82a064b8971eb5e717ce84f3ded6dbfd
Para esclarecer a resposta útil de @ John - que permite comparar um determinado hash com seu arquivo em um comando:
Digite shasum -a 256 -c <<<
,
seguido por um espaço opcional,
seguido por um único tick ( '
),
seguido pelo hash para comparar,
seguido por um espaço,
seguido por um caractere de modo, com base em como o hash inicial foi gerado:
nada , se o hash foi criado com -t
ou sem opção (modo de texto, que é o padrão)
asterisco ( *
), se o hash foi criado com -b
(modo binário)
ponto de interrogação ( ?
), se o hash foi criado com -p
(modo portátil)
circunflexo ( ^
), se o hash foi criado com -0
(modo de bits)
seguido pelo caminho para o arquivo,
seguido por um único tick de fechamento ( '
).
Como no detalhamento a seguir, delinear parênteses em torno das partes do hash e do caminho do arquivo e colchetes ao redor da parte opcional "caractere de modo". ( Não inclua parênteses ou parênteses na vida real - eles estão aqui apenas para facilitar a visualização das peças! )
shasum -a 256 -c <<< '(hashToCompare) [mode character](filepath)'
Dividido :
O comando shasum real éshasum -a 256 -c
-a 256
diz shasum
para usar sha256 .
-c
diz shasum
para "verificar" a entrada fornecida.
O <<<
é um conjunto de caracteres especiais Unix / Linux, chamado de operador de "redirecionamento". É para alimentar algo em um comando anterior. Ao usá-lo, estamos dizendo que forneceremos uma sequência de informações para o shasum
comando usar como entrada.
A cadeia de informações de entrada deve ter marcações simples de abertura e fechamento, como 'some string here'
, ou nesse caso, o hash, o caractere de modo e o caminho do arquivo a serem verificados.
A parte de hash dentro da string não precisa de nada de especial - mas deve ser seguida por um espaço.
A parte do caractere de modo pode ser nada, um asterisco ( *
), um ponto de interrogação ( ?
) ou um sinal de intercalação ( ^
). Isso informa shasum
o modo com o qual o hash foi gerado. (Nota: nenhum caractere, representando o modo de texto, é shasum
o padrão.)
O filepath parte, é o caminho real para o arquivo a ser verificado.
Então, aqui está um exemplo da vida real, verificando um arquivo de download do MAMP específico em relação ao suposto valor SHA-256 . O *
caractere de modo foi necessário para que essa verificação funcionasse:
shasum -a 256 -c <<< 'f05ede012b8a5d0e7c9cf17fee0fa1eb5cd8131f3c703ed14ea347f25be11a28 *MAMP_MAMP_PRO_5.2.pkg'
Nota: o resultado deste comando (para o meu arquivo de exemplo) é -
ESTÁ BEM:
MAMP_MAMP_PRO_5.2.pkg: OK
ou
FALHOU:
MAMP_MAMP_PRO_5.2.pkg: shasum FAILED
: AVISO: 1 soma de verificação computada NÃO corresponde
shasum -c <<< '7cb77378a0749f2a9b7e09ea62ffb13febf3759f *sample.txt'
retorna a mensagem *sample.txt: FAILED open or read
. Sem o asterisco sample.txt: OK
,. Ainda não consegui encontrar a base do uso do asterisco em outro lugar. Você poderia esclarecer?
--binary
opção)? Na página do manual: "Ao verificar, a entrada deve ser uma saída anterior deste programa. O modo padrão é imprimir uma linha com soma de verificação, um caractere indicando o tipo ( *
para binário,` `para texto, U
para UNIVERSAL, ^
para BITS, ?
para portáteis) e nome para cada ARQUIVO ". Portanto, os caracteres entre a soma de verificação e o nome do arquivo dependem do modo definido quando a soma de verificação foi criada?