Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: nick65go on February 27, 2023, 02:04:52 AM
-
the /usr/bin/provides.sh will try zsync the file, and if it fails then will download the not-compressed file:
TCEDIR="/etc/sysconfig/tcedir"
DB="provides.db"
if /usr/bin/zsync -i "$TCEDIR"/"$DB" -q "$MIRROR"/"$DB".zsync
then
rm -f "$DB".zs-old
else
/usr/bin/wget -O "$TCEDIR"/"$DB" "$MIRROR"/"$DB"
fiFYI: provides.db is 22.1 MB, but provides.db.gz is 2.2 MB
-
This would be fine. Please make the change and send a patch.
-
Hi, please find attached the new provides.sh and the
diff -ad provides.sh 2provides.sh > provides.diff
-
hi curaga,
Please check the diff file. It does undesirable things IMO.
-
Hi, if you agree with explicit path for busybox external applets, and to not source /etc/init.d/tc-functions (7.2 KB), then please find attached a tce-fetch.sh (880 bytes) and its diff
diff -ad tce-fetch.sh 2tce-fetch.sh > tce-fetch.diffI believe that any incompatible bash, gnu-tools will load in /usr/local/ so they will not influence explicit busybox functions from script.
-
Please check the diff file. It does undesirable things IMO.
I admit that I am not a programmer, so please help me to improve myself, by highlighting the "undesirable things" ; thanks for the feed-back.
-
I am not a programmer either. ;)
So these are strictly IMO.
useBusybox tells the script to use BusyBox version of commands. This is important when people have downloaded GNU version of the command.
Adding the full path for commands is not the right thing to do. I know this is not consistent through out all the scripts, probably because of a missing useBusybox?
Do not copy functions from tc-functions. Fix the function in tc-functions if necessary.
-
I found a mistake in initial provides.diff
- MIRROR="${MIRROR%/}/$(getMajorVer).x/$BUILD/tcz"
+ MIRROR="${MIRROR%/}/$getMajorVer.x/$BUILD/tcz"
Anyway, the idea was/IS to do not call external script/function of 7KB for a block of text of few bytes.
If the script fits in 4KB =page in RAM, what do I loose by "my method"? Used ONLY for these small scripts.
I wish any small script to be independent/portable outside tinycore. In general you are right to use complex function, but maybe not for a 400 -800 bytes script, come on :P
FYI: is it correct that ANY new tcz (with bash, gnu tools, whatever) will be linked into /usr/local/bin, or /usr/local/sbin? So will NOT influence "my"/ these specific tc scripts which are without use_busybox.
-
Greg Erskine, may I have a joke, as between two non-programmers?
I have a A.sh script (1 KB) which needs to import / source a small function (10 bytes) from a B.sh (10 MB). Unfortunately this B.sh is scattered in100 pieces of 100 KB all over a rotation disk, not even in right order of pieces on disk to be read sequentially. How fast execution will my A.sh script archive?
So, not all the time we should play by the thumb / general rules (imposed by others on us) in any circumstances. Q.E.D.
-
In 2provides.sh:
DB=$DB.gz
if [ ! -f "$TCEDIR"/"DB" ]
/usr/bin/wget -O "$TCEDIR"/"$DB" "$MIRROR"/"$DB"
/bin/gunzip "$TCEDIR"/"DB"
fi
You missed the "$" before "DB" on the gunzip line and the test statement. Also it's pointless quoting "$DB" if you don't quote it where you append .gz on the end. Actually I sussest that you just add ".gz" on the end of the wget and gunzip lines and leave the DB variable itself alone. Plus there's no "then" statement after the "if".
I don't think you need to change other parts of the script for this purpose.
One separate problem that I have with the original provides.sh script is that read/write permission gets removed for the group (by the zsync command) whenever it's run, so only the user that owns the provides.db file can access it (it tries to download again via wget if another user runs provides.sh, because zsync can't read the existing file). Adding this at the end fixes the problem:
chmod g+rw "$TCEDIR"/"$DB"
-
- please keep other changes separate, one change per patch
- please use unified diffs (diff -u)
The change to full paths and avoiding the include would not be accepted.
CNK: that permissions change would be fine.
-
Regarding the speed of including tc-functions, it will be in cache after the first use. So its inclusion is very fast, and removing it does not bring significant benefits.
-
@curaga: yes, it is crystal clear, i understood.
@CNK please take over the patch, thank you.
-
It turns out that zsync has this logic all built in already, so the current script already downloads the provides.db.gz file and decompresses it if /etc/sysconfig/tcedir/provides.db doesn't exist. It explains itself if you remove "-q" from the zsync command. So I guess the wget part is just some backup in case the zsync program fails, or provides.db.zsync is missing on the mirror?
$ rm /etc/sysconfig/tcedir/provides.db
$ ./provides-git.sh fltk
#################### 100.0% 29.4 kBps DONE
open: No such file or directory
not using seed file /etc/sysconfig/tcedir/provides.db
Read /etc/sysconfig/tcedir/provides.db. Target 0.0% complete.
No relevent local data found - I will be downloading the whole file. If that's not what you want, CTRL-C out. You should specify the local file is the old version of the file to download with -i (you might have to decompress it with gzip -d first). Or perhaps you just have no data that helps download the file
downloading from http://mirrors.dotsrc.org/tinycorelinux/13.x/x86_64/tcz/provides.db.gz:
#################### 100.0% 363.5 kBps DONE
verifying download...checksum matches OK
used 0 local, fetched 2261741
fltk-1.3-dev.tcz
fltk-1.3.tcz
fltk-full-dev.tcz
fltk-full-man.tcz
fltk-full.tcz
fltk-xft-dev.tcz
fltk-xft.tcz
pinentry-fltk.tcz
webkitfltk-dev.tcz
Xlibs.tcz
Anyway, attached is a modified version where wget also downloads the gzip compressed version (I had to sabotage zsync to test it), and my chmod line is also added at the end. The patch is for the current version in the git repo.
-
Applied, thanks.
-
DB="provides.db"
"$MIRROR"/"$DB".zsync
Can I ask opinions about the formatting of the filename "$DB".zsync ?
options?
1. "$DB".zsync
2. "$DB.zsync"
3. "${DB}.zsync"
All work fine, I tend to use 3.
-
POSIX shells use space as field separator. Variable names must match the regex [a-zA-Z_][a-zA-Z0-9_]* (i.e., must start with a letter or underscore, followed by zero or more letters/digits/underscores). (So wacky variable names such as _ or _1 are technically permissible--if ill-advised.)
$foo is shorthand for ${foo} and the two are interchangeable most of the time. If the variable is followed by a character that is allowed to be part of a variable name, then you need ${foo} to prevent ambiguity. You can never go wrong with ${foo} but it's not needed here--shell does not allow a period to be part of variable name, so there is no ambiguity in $foo.extension
${foo}.bar and "${foo}.bar" are interchangeable unless the value of ${foo} contains a space, in which case the shell would get confused and interpret the value of ${foo}.bar as two separate things (delimited by the space inside the variable foo).
Bottomline:
From the code snipped we know that DB does not contain a space, so quotes are not required. What follows the variable name (a period) cannot be confused for being part of the variable name, so curly brackets are also not required. So all three forms you listed are fine. I've seen forms #1 and #2 in TCL scripts. Personally I'd go with #2 because it avoids me having to type the unnecessary curly brackets (vs. #3) and it would still work if the value of DB were to change in the future to include a space (vs. #1).
-
@GNUser: very nice lessons for shell, [sh]. Good to have them here for quick reference.
-
I did some tests. If var contains a space, "$var".zsync and "$var.zsync" both work. The shell sees both as a single argument. Only $var.zsync (without any quotes) would be a problem because it would be seen as two arguments.
I've been shell programming for over a decade and just learned something new today :)
Gentlemen, the three forms are completely interchangeable. Form #3 just has two extra characters.
-
Thanks for the feedback.
-
Hi GNUser
While my preference is to wrap $VAR+text references in quotes, I have run
into some corner cases where the shell thinks the variable is called VARtext.
I think it might have been when VAR ended in or text had a leading - or _
Nowadays I first echo "$VARtext" to make sure it behaves the way I expect
it to, or just write it as "$VAR"text out of caution.
-
Hi Rich. I also generally wrap all of $VARtext in quotes, but you are right (as usual) in saying this will fail in rare corner cases.
"${VAR}text" would always work. "$VAR"text would also always work. "$VARtext" will only fail in the corner case where text has a leading alphanumeric character or underscore. (If text has a leading hyphen or period, no problem because the shell would never interpret those characters as being part of the variable name.)
-
Which why I use like to use "${VAR}text" even if there is a period as the first text character. To me, it's like aways putting double quotes around a variable name if it is a string.
I have been caught out before and it's not always easy to see.