Strange construct in BASH script file

I am NOT a BASH expert by any stretch of the word, so I may have my ignorance to blame on this.

I picked up a script for the Raspberry Pi that will, when run, give you a report about all sortd of things about your system. I ran this script aftrer looking it over and it works in all areas except the one I have included below. This part of the script will give info regarding the "Speed Governor" whether it is "ondemand" or otherwise.

The problem arises on the IF ststement. The error is too many parameters. It looks like the "-a" is something I have never seen in an IF statement and I can find no reference to it anywhere.

Can you more experienced BASH script writers take a look at this etion of script and tell me where I missed the boat?

The section of script: #=========================================================== \#!/bin/bash

# system_info.sh LINE="---------------------------------------------------------------

-------" ## somecommands that work fine

echo "${LINE}" echo " SPEED GOVERNOR" GOV=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor) FORCE=$(grep "^force_turbo=" /boot/config.txt | cut -f2 -d"=") ##### the following line gives the error if [ ${GOV} = "ondemand" -a ${FORCE} = "1" ] then echo "(...but overridden by \"force_turbo=1\" found in config.txt)" fi echo ## remainder of script after this but not shown #======================================================== End of script

I have not tried this on any other software but Raspberry Pi OS

Thank you for your assistance.

John Carter

Reply to
John Carter
Loading thread data ...

John,

Have you echo-ed both the variables yet ? What happens when FORCE is an empty string ?

Just tested it, and I get the same error. When I replace the "FORCE=" line with "FORCE=None" the error disappears. Looking in the "/boot/config.txt" there is no "force_turbo" entry. Which causes the FORCE environment variable to become an empty string.

Don't know what the shortest way to solve it though ...

Regards, Rudy Wieser

Reply to
R.Wieser

It is documented in the manpage for test. The open square bracket in that if statement is not punctuation, it is the test command (if you look in /bin you should find that [ and test are links to the same file (use ls

-i)). The -a flag for test is a logical and.

I'd suggest quoting ${GOV} and ${FORCE} in that statement one or other may be empty which without quotes will break the syntax of the test command arguments.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

the open square bracket is usually

/usr/bin/[

which might be a hard or soft link to /usr/bin/test

so that line expands to

if /usr/bin/test ${GOV} = "ondemand" -a ${FORCE} = "1"

the -a relates to the "test" command, not to the "if" statement.

the -a argmument to "test" can be used either to test for existence of a file, or as in this case as a boolean "and" clause

I suspect your issue is that one of your bash variables is unset, or has ended up with a special character in it, put echo ${GOV} and echo ${FORCE} statements in there for debugging ...

Reply to
Andy Burns

Ahem and Andy are correct. Ignore Wieser. Always always *always* quote variables in if statements (aka. tests, and yes -a means "and" here) because they can be empty or there can be problematic characters inside them, like a space.

if [ "${GOV}" = 'ondemand' -a "${FORCE}" = '1' ]

Reply to
A. Dumas

John,

I would suggest you listen do dumbass sorry, Dumas there, even though Ahem and Andy said the same as I did and did not post a solution either.

And even though dumbass, sorry, Dumas there has nothing to add to what Ahem, Andy and I already said - other pointing out something that isn't part of your problem and also doesn't often exist (understatement) in simple words like you used.

As for the solution ? I overthought it. The problem is that the FORCE variable may be an empty string. The solution ? Make sure that the compared-with string is never empty. How ? Prefix a character - and do the same to the other side of the comparision.

In short, something like this:

change

${FORCE} = "1"

to

"!"${FORCE} = "!1"

Thats all. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

I decided to post clues, rather than finish John's homework for him ...

Reply to
Andy Burns

Andy,

It was not ment as any kind of accusation towards you, but as a "any reason why you picking me out ? I said the same as two other posters" towards dumbass, sorry Dumas there.

My apologies if I crossed your intention in trying to guide the OP to doing his own work though.

Regards, Rudy Wieser

Reply to
R.Wieser

rewrite as:

if [ "${GOV}" = "ondemand" ] && [ "${FORCE}" = "1" ]

--
Kees Nuyt
Reply to
Kees Nuyt

I posted a solution - the correct one viz:

OK I didn't explicitly write out the corrected version. Like Andy I prefer to help people think and understand.

Twice and still got it wrong!

It might also contain spaces, tabs, newlines etc.

BAD SOLUTION! I've been seeing this bad solution used since the mid

1980s, it was a bad idea then and it still is today.

Try FORCE="Silly boy this doesn't work" in your version. Quoting the variable expansion is the correct solution viz:

"${FORCE}" = "1"

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

[snip]

Really, are you like five years old?

---druck

Reply to
druck

Well, it *is* the basis for my alias. Call me alexandre, I am just a regular dumas and aren't we all? Which was the running joke in another group I followed.

formatting link

Reply to
A. Dumas

Ahem,

It was not about you or Andy. All three of us wrote the similar thing: Check the variables, as one being empty is the likely cause of the problem.

The thing is that Dumas there singled me out. For what reason ? He still has to tell us..

The same here. Why did you think I suggested to print out the GOV and FORCE variables ?

...

Yeah, that was something I didn't think about ...

And yes, wrapping the environment variable into double quotes does seem to do the trick. Even though my tests in that direction initially failed - because I removed the spaces at both sides of the "=". Didn't realise BASH needs them. Yeah, I'm a rather newbie in regard to Linux and BASH. So sue me. :-)

Regards, Rudy Wieser

Reply to
R.Wieser

druck,

Yeah, thereabouts. I'm almost six though. :-)

But tell me, what do you call someone who singles someone else out, even though he didn't say anything different than two others ? And without mentioning why he does. In our play yard we call that a bully. What do they call such people at your age ?

Regards, Rudy Wieser

Reply to
R.Wieser

The root cause of 99.9% of all software problems right there.

It is also standard best practice for shell programming and has been for decades.

It's nothing to do with bash, and everything to do with /bin/test aka /bin/[.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

Another solution, not decades old, is to use double brackets [[ which is a keyword, not a built-in like [ or test, and within which Bash does not split words. Also allows ==,&&,etc. which are probably clearer to programmers not living in Bash. This prints yes:

t='a b'; if [[ $t == 'a b' ]]; then echo yes; else echo no; fi

(but I would still use double quotes "$t" every time...)

Reply to
A. Dumas

Well I've been around Unix since the '80s and I STILL can't write complex shell scripts. Its always been quicker to write the thing in C.

--
There?s a mighty big difference between good, sound reasons and reasons  
that sound good. 
 Click to see the full signature
Reply to
The Natural Philosopher

However that only works in bash so be sure to specify bash in the shebang rather than /bin/sh which may be something more like a real Bourne shell and not support extensions like [[.

For shell scripts I prefer to restrict myself to Bourne shell syntax for portability reasons.

Yes.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

-a is the logical AND operator. What's likely causing an error is if either $GOV or $FORCE are empty, the command parses out to something like this:

if [ = "ondemand" -a = "1" ]

That obviously makes no sense. In any bash comparison, quote your variables:

if [ "${GOV}" = "ondemand" -a "${FORCE}" = "1" ]

That way, if they're empty, the command parses like this:

if [ "" = "ondemand" -a "" = "1" ]

which evaluates as false, instead of returning an error.

_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(

formatting link
Top-posting! \_^_/ >What's the most annoying thing on Usenet?

Reply to
Scott Alfter

Ah yes but the script did specify #!/usr/bash :) As this was a very Pi-specific script, I think portability isn't an issue.

Reply to
A. Dumas

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.