#1915 Issue closed: function xfs_parse may show error "filesystems-functions.sh: line 221: [: -eq: unary operator expected"¶

Labels: fixed / solved / done, minor bug

jsmeix opened issue at 2018-09-21 12:58:¶

The function xfs_parse may show error messsages like
filesystems-functions.sh: line 221: [: -eq: unary operator expected
cf.
https://pastebin.com/VjPfvRHU
from
https://github.com/rear/rear/issues/1912#issuecomment-423233369

In current ReaR master code lib/filesystems-functions.sh
looks as follows:

# cat -n /usr/share/rear/lib/filesystems-functions.sh
...
    37  function xfs_parse
...
   220              # crc and ftype are mutually exclusive
   221              if [ $crc -eq 1 ] && [ $var = "ftype" ]; then

I assume sometimes $crc can be unset or empty which results
the [: -eq: unary operator expected error message as in

# if [ -eq 1 ] ; then echo y ; fi
bash: [: -eq: unary operator expected

FYI:
Quoting does not help

# if [ "" -eq 1 ] ; then echo y ; fi
bash: [: : integer expression expected

but specifying a fallback value helps

# if [ ${foo:-0} -eq 1 ] ; then echo y ; else echo n ; fi
n

gozora commented at 2018-09-24 07:59:¶

Hello @jsmeix,

I'll check that later today ...

V.

gozora commented at 2018-09-24 16:47:¶

Either I've terribly miscalculated (assuming crc=[0-9] is always present in xfs_info) or there is something wrong with xfs layout files ...

@will-code-for-pizza would you mind pasting here output from cat /var/lib/rear/layout/xfs/*.xfs command ?

gozora commented at 2018-09-24 16:47:¶

Sorry, for closing by accident ;-)

gozora commented at 2018-09-24 18:07:¶

After installing Centos6 I was able to reproduce this problem:

[root@centos69 ~]# xfs_info -V
xfs_info version 3.1.1

[root@centos69 ~]# xfs_info /data/
meta-data=/dev/sdb1              isize=256    agcount=4, agsize=274240 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=1096960, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Indeed older (probably version 3) version of xfsprogs, does not know about crc option, so yet another difference. :-(

At the first glance using if [ ${foo:-0} -eq 1 ], proposed by @jsmeix (https://github.com/rear/rear/issues/1915#issue-362603876) would be the simplest hence best solution of this problem.

In upcoming days, I'll do couple of tests and prepare PR

@will-code-for-pizza you can ignore my request (https://github.com/rear/rear/issues/1915#issuecomment-424044409) for sending cat /var/lib/rear/layout/xfs/*.xfs command output.

V.

jsmeix commented at 2018-09-26 08:03:¶

With https://github.com/rear/rear/pull/1918 merged
this issue should be fixed.

---

[Export of Github issue for rear/rear.]