puzzle

General
1

Da gerade viel los ist, möchte ich auch etwas beitragen.

#!/bin/bash
if [ "$#" != "1" ] ; then
    echo "enter an integer"
    exit 0
fi
[ "$1" -eq "$1" ] 2>/dev/null
if [ "$?" -ne 0 ] ; then
    echo "not an integer"
    exit 0
fi
cnt=$1
bs=1
while [ $((cnt%2)) -eq 0 ] ; do
    bs=$((bs*2))
    cnt=$((cnt/2))
done
echo "bs=$bs count=$cnt"

Was berechnet das Skript?
Was kann man damit machen?
Warum benutzt es niemand oder habe ich jemanden übersehen?

Viel Spaß
Franz
mit deepl:----------------------
Dato che c'è molto da fare in questo momento, vorrei contribuire anch'io.

Cosa calcola lo script?
Cosa si può fare con esso?
Perché nessuno lo usa o ho trascurato qualcuno?
Buon divertimento
Franz

2

# count returns the rest of division of the entered integer by 2; if count=1 the integer was a power of 2
# bs * count gives the original integer
# bs=1 indicates that the inetegr was odd
# ----------------------------------------

~/temp$ cat ./puzzle.sh
#!/bin/bash
# puzzle over sh/bash proposed by Franz L. on
# June 29, 2023 6:37 PM, "Franz Linter" <franz.linter(a)lugbz.org>
if [ "$#" != "1" ] ; then
    echo "enter an integer"
    exit 0
fi
[ "$1" -eq "$1" ] 2>/dev/null
if [ "$?" -ne 0 ] ; then
    echo "not an integer"
    exit 0
fi
cnt=$1
bs=1
while [ $((cnt%2)) -eq 0 ] ; do
    bs=$((bs*2))
    cnt=$((cnt/2))
done
echo "bs=$bs count=$cnt"
# ----------------------------------------------
~/temp$ for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ; do echo -- $i ; ./puzzle.sh $i ; done
-- 1
bs=1 count=1
-- 2
bs=2 count=1
-- 3
bs=1 count=3
-- 4
bs=4 count=1
-- 5
bs=1 count=5
-- 6
bs=2 count=3
-- 7
bs=1 count=7
-- 8
bs=8 count=1
-- 9
bs=1 count=9
-- 10
bs=2 count=5
-- 11
bs=1 count=11
-- 12
bs=4 count=3
-- 13
bs=1 count=13
-- 14
bs=2 count=7
-- 15
bs=1 count=15
-- 16
bs=16 count=1
-- 17
bs=1 count=17
-- 18
bs=2 count=9
-- 19
bs=1 count=19
-- 20
bs=4 count=5
-- 21
bs=1 count=21
-- 22
bs=2 count=11
-- 23
bs=1 count=23
-- 24
bs=8 count=3
-- 25
bs=1 count=25
-- 26
bs=2 count=13
-- 27
bs=1 count=27
-- 28
bs=4 count=7
-- 29
bs=1 count=29
-- 30
bs=2 count=15
-- 31
bs=1 count=31
-- 32
bs=32 count=1
-- 33
bs=1 count=33
# ----------------------------------------------

June 29, 2023 6:37 PM, "Franz Linter" <franz.linter(a)lugbz.org> wrote:

3

diego.maniacco(a)lugbz.org wrote:

bs=1
while [ $((cnt%2)) -eq 0 ] ; do
   bs=$((bs*2))
   cnt=$((cnt/2))
done

This loop could be replaced with:

bs="$((cnt & ~(cnt -1)))"
cnt=$((cnt / bs))

Thomas :slight_smile:

4

Giusto. Ma hai citato solo gli estremi. Per la domanda 1 mi aspettavo la
seguente risposta.
Lo script determina 2 fattori del numero inserito. bs è la più grande
potenza di due possibile che divide il numero dato senza resto. count =
numero dato/bs

Come promemoria, le domande erano:

Cosa calcola lo script?
Cosa si può fare con esso?
Perché nessuno lo usa o ho trascurato qualcuno?

Con il riferimento a dd, ho svelato quasi tutto.

Per me, le risposte sono un'altra conferma del fatto che ovviamente
nessuno controlla nulla, il che può evitare una noiosa risoluzione dei
problemi. Poiché mi è successo una volta, lo faccio sempre.

Saluti, Franz

5

I now bring the resolution in English.

The script calculates the parameters bs and count from the file length
of the .iso file for the call of dd, so that exactly the desired bytes
are transferred.

It is not so much about how to copy an image to a stick, but how to
check the copying process as quickly as possible using the known hash.
Or how to check later whether the content of the stick has changed.

In order to obtain the same hash for an error-free copying process,
exactly as many bytes must be read as written.

So that this does not take too long, the trivial solution bs=1 and
count=size should be avoided. Further below you will find some
information about the times, which differ considerably, especially with
large files.

The remedy is the calculated parameters of the script. If a bs smaller
than 512 is calculated, which has never happened to me, reading takes a
little longer. bs with several MiBs are processed in smaller parts anyway.

The question remains: am I the only one doing this check? Why is the
hash checked when downloading but not when writing?

I have searched 2 times for a long time for errors caused by bad sticks
and looked for a solution and built myself a script. Not long ago I had
strange phenomena after an installation. I checked the stick because I
hadn't used my script to copy and the hash didn't match, copied again
and the phenomena were gone.

I would like to point out Thomas Pircher's elegant variant, which
achieves the same thing without a loop with a bit operation, namely the
largest possible power of two dividing the file length without remainder.

bs="$((cnt & ~(cnt -1)))"
cnt=$((cnt / bs))

However, I recommend that in your own scripts you only use command
combinations that you understand.

Here is the influence of the parameters on the time. bs=1 is
catastrophically bad.

localhost:~ #time dd if=/dev/sdb bs=1 count=2147483648| sha256sum
2147483648+0 records in
2147483648+0 records out
7006df13cead40a8e19b0a63849e957da6c9eb0291bf4cf13401dcd43129f9de -
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 2297.46 s, 935 kB/s

real 38m17.466s
user 6m26.279s
sys 52m45.180s
localhost:~ #time dd if=/dev/sdb bs=16777216 count=128| sha256sum
128+0 records in
128+0 records out
7006df13cead40a8e19b0a63849e957da6c9eb0291bf4cf13401dcd43129f9de -
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 128.502 s, 16.7 MB/s

real 2m8.504s
user 0m10.391s
sys 0m2.317s
localhost:~ #time dd if=/dev/sdb bs=512 count=4194304| sha256sum
4194304+0 records in
4194304+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 118.927 s, 18.1 MB/s
7006df13cead40a8e19b0a63849e957da6c9eb0291bf4cf13401dcd43129f9de -

real 1m58.929s
user 0m19.580s
sys 0m9.095s
localhost:~ #time dd if=/dev/sdb bs=4096 count=524288| sha256sum
524288+0 records in
524288+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 118.817 s, 18.1 MB/s
7006df13cead40a8e19b0a63849e957da6c9eb0291bf4cf13401dcd43129f9de -

real 1m58.819s
user 0m18.354s
sys 0m3.578s
localhost:~ #

Franz

attachment.html (6.53 KB)

6

Tnks!

Da gerade viel los ist, möchte ich auch etwas beitragen.

#!/bin/bash
if [ "$#" != "1" ] ; then
echo "enter an integer"
exit 0
fi
[ "$1" -eq "$1" ] 2>/dev/null
if [ "$?" -ne 0 ] ; then
echo "not an integer"
exit 0
fi
cnt=$1
bs=1
while [ $((cnt%2)) -eq 0 ] ; do
bs=$((bs*2))
cnt=$((cnt/2))
done
echo "bs=$bs count=$cnt"

Was berechnet das Skript?
Was kann man damit machen?
Warum benutzt es niemand oder habe ich jemanden übersehen?

Viel Spaß
Franz
mit deepl:----------------------
Dato che c'è molto da fare in questo momento, vorrei contribuire anch'io.

Cosa calcola lo script?
Cosa si può fare con esso?
Perché nessuno lo usa o ho trascurato qualcuno?
Buon divertimento
Franz
-------------------------------------
Since there is a lot going on right now, I would also like to contribute

something.

What does the script calculate?
What can you do with it?
Why doesn't anyone use it or have I overlooked someone?

Have fun
Franz

I now bring the resolution in English.

The script calculates the parameters bs and count from the file length of

the .iso file for the call of dd, so that exactly the desired bytes are
transferred.

It is not so much about how to copy an image to a stick, but how to check

the copying process as quickly as possible using the known hash. Or how to
check later whether the content of the stick has changed.

In order to obtain the same hash for an error-free copying process,

exactly as many bytes must be read as written.

So that this does not take too long, the trivial solution bs=1 and

count=size should be avoided. Further below you will find some information
about the times, which differ considerably, especially with large files.

The remedy is the calculated parameters of the script. If a bs smaller

than 512 is calculated, which has never happened to me, reading takes a
little longer. bs with several MiBs are processed in smaller parts anyway.

The question remains: am I the only one doing this check? Why is the hash

checked when downloading but not when writing?

I have searched 2 times for a long time for errors caused by bad sticks

and looked for a solution and built myself a script. Not long ago I had
strange phenomena after an installation. I checked the stick because I
hadn't used my script to copy and the hash didn't match, copied again and
the phenomena were gone.

I would like to point out Thomas Pircher's elegant variant, which

achieves the same thing without a loop with a bit operation, namely the
largest possible power of two dividing the file length without remainder.

bs="$((cnt & ~(cnt -1)))"
cnt=$((cnt / bs))

However, I recommend that in your own scripts you only use command

combinations that you understand.

Here is the influence of the parameters on the time. bs=1 is

catastrophically bad.

attachment.html (6.08 KB)