/usr/bin/ucfr: line ... : [: : integer expression expected

[Andy]

I've had a reoccurring issue: https://ubuntuforums.org/showthread.php?t=2350682
Running: ucf_3.0036_all.deb

http://askubuntu.com/questions/875415/usr-bin-ucfr-errors-integer-expression-expected
http://serverfault.com/questions/827873/grub-pc-update-fail-dev-sda-ext2-doesnt-support-embedding

I don't know why ucfr is erroring out but the accumulated errors are now enough to stall priority packages which I feel hamstrung about. I've reinstalled the ucf package and danced around the issue enough.

Any maintainers have a shot in the dark for why this would be happening?

Discussion: https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737

[Steve Langasek (vorlon)]

> I've had a reoccurring issue: https://ubuntuforums.org/showthread.php?t=2350682

Please include full error messages in your bug report when filing, rather than referring to other websites.

In this case, the error is that "count" is undefined in the script. Is /var/lib/ucf/registry missing from your system?

[Andy (ciordia9)]

I don't mean to just link outwards, I did link to the request from the 'Answers' section on here where a full discourse and general looking at has occurred:

https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737

Which in it details the registry and other components herein. I'd love to just fold that commentary here as it has deep relevance to your thinking, however the system doesn't seem to do that when you make an 'Answer' a 'Bug report'.

Outward bound if you choose not to reference my post(s):

Headless server usage here with Linode VPS. I've had an error creep into my install and it's finally caused me enough serious issue that I have to find a solution to it. I started a thread over on Ask but I haven't got any good noggins to throw some light or ideas that I can troubleshoot down further.

http://askubuntu.com/q/875415/602869

Many packages install/update just fine. A few chads have formed along these lines:

/usr/bin/ucfr: line 323: [: : integer expression expected
/usr/bin/ucfr: line 110: [: : integer expression expected

And they are causing packages to not finish their configurations and thus never finish the action. At this point its happened in a grub-pc / grub2 package and I fear that in trying to solve the end of the problem, I might have made things worse in that I cannot reboot until I resolve whatever this issue is at the head.

--

It isn't an across the board issue. Some packages I see this pop up and they clean up just fine. Currently, however, grub-pc & grub2, along with dovecot-core will not finish their installs due to this.

[Andy (ciordia9)]

Related commentary #28 from Ask thread:
[....]
"This all seems to be related to http://www.grymoire.com/unix/CshTop10.txt (search for 'Illegal variable name.')

Still there is the open question, why you get different results between "grep -E ..." and "egrep ..."

What I can suggest:
1. avoid tcsh and csh when updating your system, because ucfr might fail
2. suggest that ucfr avoids the string $" because grep will fail if tcsh or csh is used. (this should go into the bug report)"

[Steve Langasek (vorlon)]

You don't appear to have answered the key question from my follow-up.

> In this case, the error is that "count" is undefined in the script.
> Is /var/lib/ucf/registry missing from your system?

[Manfred Hampl (m-hampl)]

/var/lib/ucf/registry is present on the system with the problem (see https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737 )

As far as we already found out one of the causes of this error is that the command
egrep --count "[[:space:]]/etc/default/grub$" "/var/lib/ucf/registry"
returns
"Illegal variable name."
when executed in a csh or tcsh shell.
According to http://www.grymoire.com/unix/CshTop10.txt any use of the string $" in a csh or tcsh fails that way.

According to suggestions in the grymoire document, a potential workaround could be changing line 321 of ucfr from
count=$(egrep --count "[[:space:]]${real_conf_file_re}$" "$statedir/registry") || true
into
count=$(egrep --count "[[:space:]]${real_conf_file_re}"'$' "$statedir/registry") || true
(instead of 'dollar doublequote' make it 'doublequote quote dollar quote')
(Note, I was not in a position that I could test myself whether this works.)

[Steve Langasek (vorlon)]

On Tue, Feb 07, 2017 at 04:32:19PM -0000, Manfred Hampl wrote:
> /var/lib/ucf/registry is present on the system with the problem (see
> https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737 )

> As far as we already found out one of the causes of this error is that the command
> egrep --count "[[:space:]]/etc/default/grub$" "/var/lib/ucf/registry"
> returns
> "Illegal variable name."
> when executed in a csh or tcsh shell.

It's not being executed in a csh or tcsh shell. /usr/bin/ucfr is a
/bin/bash script. If /bin/bash on your system is pointing to a csh
implementation, you get to keep both pieces.

[Andy (ciordia9)]

Good idea to check bash, however:

root@nexus:/bin# ls -al bash
-rwxr-xr-x 1 root root 1037528 Jun 24 2016 bash

[Manfred Hampl (m-hampl)]

Meanwhile in https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737 we identified two areas where the ucfr script misbehaved in the environment of the original poster.

The following workarounds helped:

Change all occurrences of $" into "'$'
Change all occurrences of egrep into grep -E

Even if we do not know why the ucfr script failed in the original poster's environment, these modifications might be worth being considered for future versions of the ucfr script.

[Steve Langasek (vorlon)]

On Fri, Feb 17, 2017 at 10:11:51PM -0000, Manfred Hampl wrote:
> Meanwhile in
> https://answers.launchpad.net/ubuntu/+source/ucf/+question/448737 we
> identified two areas where the ucfr script misbehaved in the environment
> of the original poster.

> The following workarounds helped:

> Change all occurrences of $" into "'$'
> Change all occurrences of egrep into grep -E

> Even if we do not know why the ucfr script failed in the original
> poster's environment, these modifications might be worth being
> considered for future versions of the ucfr script.

Except the fact that these changes helped point to a fundamentally broken
install, not a bug in ucfr.

[Andy (ciordia9)]

Except that the dozen of frozen packages that were also experiencing the same UCFR error were resolved once the ucfr script was tweaked. Just because one package continued to have a fundamental flaw doesn't mean the others were. FWIW.

[Steve Langasek (vorlon)]

On Sat, Feb 18, 2017 at 04:30:17PM -0000, Andy wrote:
> Except that the dozen of frozen packages that were also experiencing the
> same UCFR error were resolved once the ucfr script was tweaked. Just
> because one package continued to have a fundamental flaw doesn't mean
> the others were. FWIW.

No, the fact that the tweaks to the ucfr script helped means your
installation *as a whole* is corrupted. egrep is /bin/egrep, which is part
of the grep package. There is no reason for egrep to fail, but grep -E to
work, except a corrupted system. Likewise, the '$' syntax is valid bash
shell syntax, so if this is failing, somehow the script is being run under
an interpreter that isn't bash.

[Andy (ciordia9)]

Yea I have no idea, this hasn't had a dist-upgrade in its life-cycle to introduce some weird malfunction. I've reinstalled bash and grep throughout this. You're right though egrep is nothing but a passthrough to grep. Maybe something upstream is corrupt.

One would think I'd see more rampant issues though besides a few packages being held up in post configuration stages though. Having it so isolated is weird enough.

If there is something ticking around I'll work on a migration/refresh when I can schedule the offloading of everything. Joy of joys.

[Launchpad Janitor (janitor)]

[Expired for ucf (Ubuntu) because there has been no activity for 60 days.]