Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pattern error message #130

Open
brunoagneray opened this issue Apr 6, 2023 · 2 comments
Open

Pattern error message #130

brunoagneray opened this issue Apr 6, 2023 · 2 comments
Assignees
Labels
Milestone

Comments

@brunoagneray
Copy link

Hi,

We use lbnl-nhc-1.4.3-1 version.

We have nodes with name like cluster-n[01-99] and storage nodes with name like cluster-nfs[01-99].

We have the following lines in our nhc.conf file :

{cluster-n[01-99]} || export NHC_RM=
{cluster-nfs[01-99]} || export NHC_RM=

When executing the command 'nhc -a' on a storage node in cluster-nfs, we encounter the following error message like :

/etc/nhc/scripts/common.nhc: line 201: [[: 10#fs15: value too great for base (error token is "10#fs15")

Regards,

Bruno

@mej
Copy link
Owner

mej commented Apr 20, 2023

I think what's going on here is that NHC is getting confused by the fact that the leading portion (what the code refers to as the PREFIX) of the hostname cluster-nfs15, when matched against the range expression cluster-n[01-99], is taken to be cluster-n. Once that gets trimmed off, it then tries to treat the remainder of the hostname (i.e., fs15) as a number that it then tries to compare with the range 01-99 to see if the "number" fs15 falls within that range.

Because Bash auto-interprets numbers in bases other than 10 under certain circumstances, the range-matching code prepends 10# to the numeric variables to ensure they get treated as base-10 numbers in all cases. In this situation, however, fs is getting erroneously lumped into the numeric value, and as the error message says, f and s don't fall within the range of digits that are valid for base-10 numbers.

I'll see if I can reproduce the problem myself by hand, but if you'd be willing to attach the output from running nhc -ax on that cluster-nfs15 host, that'd help a lot! 😀 In the meantime, though, the error shouldn't be causing any actual breakage -- range expression matching should still be working accurately, right?

Thanks for reporting the bug!

PS: As a possible workaround, for the time being, you could change to a glob expression like cluster-n[0-9][0-9] or a regular expression like /^cluster-n[[:digit:]]+$/.

@mej mej self-assigned this Apr 20, 2023
@mej mej added the bug label Apr 20, 2023
@mej mej added this to the 1.4.4 Release milestone Apr 20, 2023
@brunoagneray
Copy link
Author

brunoagneray commented Apr 21, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants