Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: andyj on January 01, 2021, 07:00:18 AM
-
It would be nice if there were a "major" version option in /usr/bin/version, that would just return 10, 11, etc. without the minor versions:
--- /usr/bin/version 2020-03-30 10:38:10.000000000 +0000
+++ version-m 2021-01-01 14:53:49.126637566 +0000
@@ -7,7 +7,7 @@
. /etc/init.d/tc-functions
useBusybox
RESULTS="$(cat /usr/share/doc/tc/release.txt)"
-while getopts cls OPTION
+while getopts clsm OPTION
do
case ${OPTION} in
c) LATEST=`wget -q -O - $(cat /opt/tcemirror)/latest-$(getBuild) 2>/dev/null`
@@ -27,6 +27,9 @@
s) echo "${RESULTS##*_}"
exit
;;
+ m) echo "${RESULTS%.*}"
+ exit
+ ;;
esac
done
echo "$RESULTS"
This doesn't help me going back, but at least it would cover all the new versions.
-
Hi andyj
You know /etc/init.d/tc-functions provides that function:
tc@E310:~$ . /etc/init.d/tc-functions; echo $(getMajorVer)
10
tc@E310:~$
-
I was looking for a way to do it with less code, not more. Plus, this looks like some duplication of "version" parsing the release.txt file. Implementing the version patch, getMajorVer goes from:
getMajorVer() {
awk '{printf "%d", $1}' /usr/share/doc/tc/release.txt
}
to
getMajorVer() {
version -m
}
Lets update both /usr/bin/version and /etc/init.d/tc-functions.
-
Hi andyj
I was looking for a way to do it with less code, not more. ...
No argument here. I was just pointing out that /usr/bin/version already sources /etc/init.d/tc-functions which already
provides getMajorVer.
I like your solution because it provides simplicity and consistency. Many scripts depend on tc-functions as a source of
common Tinycore functions. That leaves me with one question, should a file of common functions rely on an eternal script?
-
/etc/init.d/tc-functions uses /usr/bin/autoscan-devices, which is a separate executable. Compiled code versus shell script for executables is splitting hairs, I would say. The version command sources /etc/init.d/tc-functions, so why not update tc-functions and version so the work is done in tc-functions and version is just a quick way of calling the particular function:
tc@box:~$ diff tc-functions.orig /etc/init.d/tc-functions
--- tc-functions.orig
+++ /etc/init.d/tc-functions
@@ -273,10 +273,15 @@
} ' "$1"
}
-getMajorVer() {
-awk '{printf "%d", $1}' /usr/share/doc/tc/release.txt
+getFullVer() {
+verid=$(grep VERSION_ID /etc/os-release)
+echo ${verid#*=}
}
+getMajorVer() {
+fullver=$(getFullVer)
+echo ${fullver%.*}
+}
getBuild() {
BUILD=`uname -m`
tc@box:~$ diff version.orig /usr/bin/version
--- version.orig
+++ /usr/bin/version
@@ -6,8 +6,8 @@
. /etc/init.d/tc-functions
useBusybox
-RESULTS="$(cat /usr/share/doc/tc/release.txt)"
-while getopts cls OPTION
+RESULTS="$(getFullVer)"
+while getopts clsm OPTION
do
case ${OPTION} in
c) LATEST=`wget -q -O - $(cat /opt/tcemirror)/latest-$(getBuild) 2>/dev/null`
@@ -25,6 +25,9 @@
exit
;;
s) echo "${RESULTS##*_}"
+ exit
+ ;;
+ m) echo "$(getMajorVer)"
exit
;;
esac
Yes, I used the relatively new and more standard /etc/os-release instead of the classic TC specific /usr/share/doc/tc/release.txt.
-
Hi andyj
Very nice. I think that's a much cleaner solution. I would say wait and see if curaga or Juanito have comments and
express interest in a patch.
-
Ok to me.
-
Hi andyj
Unless someone else objects, you should submit your patches as files so they can be incorporated in the next release.
I'm not sure if they should be attached to this thread, submitted to:
http://patches.tinycorelinux.net/
or through github.
-
GitHub would be better :)
-
I didn't have any success getting any patches in through github, so here they are.
-
added to git - thanks
Edit: I see password authentication is depreciated :(
-
Juanito, you can still use https, you just need to create a Personal Access Token, instead of your password. (Its under developer settings)
I was also reviewing the version changes in git. tc-functions is now pointing to /etc/os-release to get it's version. However, tc-config is still looking at /usr/share/tc/release.txt. Would it not make more sense to point everything at os-release, and then remove /usr/share/tc/release.txt?
-
It would seem to make more sense to use one location for the version - is /usr/share/tc/release.txt used anywhere else?
-
I did a grep in Corescripts, and did non see any, other than tc-config.
I would hope any scripts in extensions use tc-functions.
-
Hi Juanito
I ran a grep on all directories (except /proc and /sys) for "release.txt" on my TC10 x86 machine and found only the
3 instances currently mentioned.
-
OK - could somebody submit a patch/pull request to tc git?
-
Sure will. I'm going to update the picore Branch too.
-
Maybe we should make /usr/share/doc/tc/release.txt a symlink to /etc/os-release for TC 12 only, so people who might be using it can transition?
-
The format is different, so a symlink would break things anyway.
-
It will break somebody's scripts somehow regardless. The trick would be to try to break it in a nice way, if there is such a thing.
-
Well nothing will happen until a new release occurs. So it's not like running tc-update will break things.