#2372 Issue closed: PROGS contains an empty string as its first element

Labels: cleanup, fixed / solved / done, minor bug

OliverO2 opened issue at 2020-04-16 09:02:

  • ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.5 / Git

  • Log message:

2020-04-15 21:24:08.533444817 Testing that each program in the PROGS array can be found as executable command within the recovery system
basename: missing operand
Try 'basename --help' for more information.
  • Can be fixed by changing conf/Linux-i386.conf

    • from PROGS=( "${PROGS[@]:-}" grub lilo )

    • to PROGS+=( grub lilo )

OliverO2 commented at 2020-04-16 09:03:

@jsmeix
I am aware of your recent changes to array variable handling. This is just another one I had detected by looking at the log file.

pcahyna commented at 2020-04-16 09:53:

related discussion: #2220

In that issue, I advocated removing such empty elements in lists, while @jsmeix advocated guarding against them in places which iterate over those lists, i.e. make sure everything behaves properly even in presence of those empty items.

jsmeix commented at 2020-04-16 09:56:

@OliverO2
thank you for finding more such cases!

I know that my current regexp

grep -q '[[:alpha:]_][[:alpha:]_]*=( "${[[:alpha:]_][[:alpha:]_]*\[@\]'

cf. https://github.com/rear/rear/issues/2364#issue-599621303
does not find all of them but I use it as a start to find most of them
and after I had fixed those I will do some more advanced search.

Those dummy initial empty array elements are no longer needed
when ARRAY+=( additional elements ) is used everywhere.
It also works to initialize an array: new_arr+=( initial elements )
so arr=( some elemets ) is only needed to overwrite an existing array.

Via
https://github.com/rear/rear/commit/a266b3c88002ce2d1e0569512b55ffd6bbcaf008
the dummy initial empty array elements usage is fixed in
usr/share/rear/conf/Linux-i386.conf

I also found dummy initial empty array elements usage in
usr/share/rear/prep/YUM/default/400_prep_yum.sh
and
usr/share/rear/prep/ZYPPER/default/400_prep_zypper.sh
where things look a bit more complicated

jsmeix commented at 2020-04-16 10:10:

@pcahyna
I think you misunderstood what I was trying to say e.g. in
https://github.com/rear/rear/issues/2220#issuecomment-527479184
and
https://github.com/rear/rear/commit/c19647fcd95f0c3f4020f39f5fad428e8359ec92#r32912521
and
https://github.com/rear/rear/commit/c19647fcd95f0c3f4020f39f5fad428e8359ec92#r32912816
and
https://github.com/rear/rear/issues/2220#issuecomment-527629760

See
https://github.com/rear/rear/issues/2220#issuecomment-526612502

So my current conclusion is to revert those things (in particular the dummy
array elements) that I had added to make the code work with 'set -u'
because those added stuff breakes other code at other places.

Therefore
https://github.com/rear/rear/issues/2364
is one part to clean up our old clumsy array usage in ReaR.

Another part is to get rid of those dummy empty array elements.

jsmeix commented at 2020-04-16 10:58:

With
https://github.com/rear/rear/commit/81f1345f67fa80e05c6eedec392a43721f6fe2d8
this issue should be (hopefully completely) fixed.

gdha commented at 2020-04-16 11:33:

@jsmeix @OliverO2 Thank you both for your extended effort to improve ReaR - we are proud to have members as you.


[Export of Github issue for rear/rear.]