On 2015-08-16 11:36, deano ferrari wrote:
>
> Is grepping for it sufficient?
>
> Code:
> --------------------
> grep VERSION_ID /etc/os-release
> --------------------
That would return the entire line, instead of only the value string,
whatever is at the right hand side of the equal sign. I don’t know how
to do that in a script, you need some code or parsing.
On 08/16/2015 09:44 AM, Carlos E. R. wrote:
> On 2015-08-16 11:36, deano ferrari wrote:
>>
>> Is grepping for it sufficient?
>>
>> Code:
>> --------------------
>> grep VERSION_ID /etc/os-release
>> --------------------
>
> That would return the entire line, instead of only the value string,
> whatever is at the right hand side of the equal sign. I don’t know how
> to do that in a script, you need some code or parsing.
No, or at least no more code or “parsing” than you get with the command
line. For example with awk:
I forgot to mention that the easiest way is probably to do the following,
which basically treats the os-release file itself as a script, so the
lines in it are code and setup environment variables that you can use
immediately without any awk/sed/grep work:
source /etc/os-release #parses the file
echo ${VERSION_ID}
Note that if you want to use these variables in a sub-shell, you’ll still
need to export them:
bash
echo ${VERSION_ID} #doesn't work
exit
export VERSION_ID
bash
echo ${VERSION_ID} #works because it was exported
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 2015-08-16 21:31, ab wrote:
> On 08/16/2015 09:44 AM, Carlos E. R. wrote:
>> That would return the entire line, instead of only the value string,
>> whatever is at the right hand side of the equal sign. I don’t know how
>> to do that in a script, you need some code or parsing.
>
> No, or at least no more code or “parsing” than you get with the command
> line. For example with awk:
Well, to me that’s “coding”. You are passing awk interpreter a very
short piece of code to run.
On 2015-08-16 21:34, ab wrote:
> I forgot to mention that the easiest way is probably to do the following,
> which basically treats the os-release file itself as a script, so the
> lines in it are code and setup environment variables that you can use
> immediately without any awk/sed/grep work:
Wow. That’s a very interesting way. Thanks.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thx,
For some reason I think what I did once upon a time was still slightly different, but the solutions described should work fine for me, the method declaring “source” is fairly close to whatever I might have been doing before.
It’s common (though I do not recommend it) to use the ‘.’ instead of the
source command, so you end up with something like:
.. /etc/os-release
There are a couple of great reasons o avoid this:
Easy to mistake that dot for something like ./etc/os-release which
will throw a permission denied error. Easy to mistake in documentation,
easy to typo, easy to misunderstand and then try to make it run as a
script, which could work (if permissions set properly) but would NOT have
the desired effect. Just do not do it.
Have you ever tried to Google the ‘.’ command? Good luck with that.
Alternatively, Googling the ‘source’ command gets relevant results pretty
easily.
Another way, that you really should not use, is ‘eval’ somehow.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
On 08/16/2015 02:36 AM, tsu2 wrote:
>
> I used to remember how to do this, but forgot and can’t seem to Google
> up the right syntax…
>
> It’s possible to display the installed OS and properties, the following
> is the command and its sample result on a current TW
>
> Code:
> --------------------
> cat /etc/os-releaseNAME=openSUSE
> VERSION=“20150612 (Tumbleweed)”
> VERSION_ID=“20150612”
> PRETTY_NAME=“openSUSE 20150612 (Tumbleweed) (x86_64)”
> ID=opensuse
> ANSI_COLOR=“0;32”
> CPE_NAME=“cpe:/o:opensuse:opensuse:20150612”
> BUG_REPORT_URL=“https://bugs.opensuse.org”
> HOME_URL=“https://opensuse.org/”
> ID_LIKE=“suse”
>
> --------------------
According to the man page, the lines are “shell compatible”
so… in your shell or script you could source in /etc/os-release and print out
shell variable values… just a hint.
> 1. Easy to mistake that dot for something like ./etc/os-release which
> will throw a permission denied error. Easy to mistake in documentation,
> easy to typo, easy to misunderstand and then try to make it run as a
> script, which could work (if permissions set properly) but would NOT have
> the desired effect. Just do not do it.
You convinced me
However, many suse scripts use the dot.
> 2. Have you ever tried to Google the ‘.’ command? Good luck with that.
> Alternatively, Googling the ‘source’ command gets relevant results pretty
> easily.
LOL
> Another way, that you really should not use, is ‘eval’ somehow.
Edit:
I just noticed your use of curly brackets… First test seems to have fixed the main problem but still needs to fix the logic (the if/then/else logic still wrong)
Having a bit of trouble using this in a simple test script…
For some reason when I run it, I’m not able to execute the comparison, for some reason the number is evaluated as some kind of function?!
Must be overlooking something…
TIA
#!/bin/bash
source /etc/os-release
export VERSION_ID
if
$VERSION_ID = "20150612" ]]
then
echo "This is Tumbleweed"
else
echo "This is something else"
fi
Yup, that was the issue.
Now, it looks like VERSION_ID changes with every TW update (The id apparently is the date of the update).
Since it appears that unlike other openSUSE versions, the id is not reliable to identify TW, there appears to be no alternative to parsing one of the other properties (likely NAME) for the string “TUMBLEWEED” to identify TW in a script.
Just a thought for the people who determine what values to use, it would be convenient if something minimal was available to identify any version of TW.
The problem of course is that every time the string “TUMBLEWEED” is returned, the sometimes daily changing id representing the date is included.
That works fine for me, though with minor changes made because I like my
syntax to be my way:
#!/bin/bash
source /etc/os-release
export VERSION_ID
if ${VERSION_ID} = '13.2' ]]; then
echo 'This is openSUSE 13.2';
else
echo 'This is something else';
fi
If you can, post the output from the following (putting in your shell
script of course):
bash -xv your-script-here.sh
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
You’re right about the . (dot) command being mistaken for something else or a typo most of the times. However the source command is not portable it does not work in sh, dash and other shells. Mind you in openSUSE sh points to bash so even if you have an sh shebang the source command will still work as expected. JFYI
#!/bin/bash
source /etc/os-release
export PRETTY_NAME
if
${PRETTY_NAME} | cut -c 32 = "(Tumbleweed) (x86_64)" ]]
then
echo "This is Tumbleweed"
else
echo "This is something else"
fi
Instead of parsing for the string “Tumbleweed” the above attempts to simply “cut” the first 32 characters of the PRETTY_NAME string value leaving the desired remaining string.
The error generated by the above
“A conditional binary operator expected”
I’m guessing is related to piping a variable and command. I’ve tried to re-construct the command without the pipe and tried a variety of brackets around that part of the statement with no effect with the idea of defining the desired operation but without success. I’m not sure why the error suggests it sees a conditional statement because that part of the statement is not conditional…
The problem I’m currently looking at is TW specific…
Unlike “13.2” which never changes, on a TW machine any time the string “Tumbleweed” is returned, the version ID is also returned which is the day of the TW update. Considering that TW changes daily or at most another day, if the system has been updated in that time the string has changed and can no longer be used to identify TW.
So, it seems that after returning whatever string you like identifying TW, you then also have to remove the part that changes leaving only the part that doesn’t change so that comparing will work beyond only a day or two.
