Script to download extensions+dependencies on other Linux distros

[xor]

I'm asking to understand the working logic!?

How do we call 32-bit dependencies on 64.bit!?

[Juanito]

Everything is explained in the first post of this thread.

[Rich]

I've attached an updated copy of  FetchExt.sh  to this post.

You can now enter multiple extensions in one command and it no longer matters whether or not you include
 .tcz  in the extension name:

Code: [Select]

tc@E310:~/Scripting/FetchExtensions/tmp/debug$ ./FetchExt.sh 9vx xt_geoip_LE_IPv4 9vx.tcz xyzzy 915resolution.tcz xyzzy.tcz
..........
tc@E310:~/Scripting/FetchExtensions/tmp/debug$I replaced excess screen output with dots to indicate progress since the  Log.txt  file has a record of all activity anyway.

This is the log file from the above command:

Code: [Select]

Sun Apr  3 22:34:50 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Processing 9vx.tcz
9vx.tcz downloaded.
9vx.tcz.md5.txt downloaded.

Sun Apr  3 22:34:55 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Processing xt_geoip_LE_IPv4.tcz
iptables.tcz downloaded.
iptables.tcz.md5.txt downloaded.
iptables.tcz.dep downloaded.
netfilter-4.19.10-tinycore.tcz downloaded.
netfilter-4.19.10-tinycore.tcz.md5.txt downloaded.
netfilter-4.19.10-tinycore64.tcz downloaded.
netfilter-4.19.10-tinycore64.tcz.md5.txt downloaded.
xt_geoip_LE_IPv4.tcz downloaded.
xt_geoip_LE_IPv4.tcz.md5.txt downloaded.
xt_geoip_LE_IPv4.tcz.dep downloaded.
xtables-addons-4.19.10-tinycore.tcz downloaded.
xtables-addons-4.19.10-tinycore.tcz.md5.txt downloaded.
xtables-addons-4.19.10-tinycore.tcz.dep downloaded.
  Error:  xtables-addons-4.19.10-tinycore64.tcz download failed.
  Error:  xtables-addons-4.19.10-tinycore64.tcz.md5.txt download failed.

Sun Apr  3 22:35:03 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Processing 9vx.tcz
9vx.tcz already downloaded.

Sun Apr  3 22:35:04 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
  Error:  Processing xyzzy.tcz failed.

Sun Apr  3 22:35:04 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Processing 915resolution.tcz
915resolution.tcz downloaded.
915resolution.tcz.md5.txt downloaded.

Sun Apr  3 22:35:05 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
  Error:  Processing xyzzy.tcz failed.The lines that begin with  Processing  refer to the extensions from the command line. That's what you add to
your onboot.lst  file,
The lines after that give the results for that extension and all dependencies.
Errors are indented for better visibility.

I've also attached a  ShowErrors.sh  script. It parses the Log.txt script created by FetchExt.sh and outputs a
formatted list of any errors found:

Code: [Select]

tc@E310:~/Scripting/FetchExtensions/tmp/debug$ ./ShowErrors.sh

Sun Apr  3 22:34:55 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Processing xt_geoip_LE_IPv4.tcz
Error:  xtables-addons-4.19.10-tinycore64.tcz download failed.
Error:  xtables-addons-4.19.10-tinycore64.tcz.md5.txt download failed.

Sun Apr  3 22:35:04 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Error:  Processing xyzzy.tcz failed.

Sun Apr  3 22:35:05 UTC 2022
http://repo.tinycorelinux.net/10.x/x86/tcz/
Error:  Processing xyzzy.tcz failed.

tc@E310:~/Scripting/FetchExtensions/tmp/debug$The  xtables-addons  error shows that the 64 bit module extension is missing from the TC10 x86 repository.
The  Error:  Processing  message means the extension you requested from the command line does not exist.

The script now creates a list of kernel versions in the repo. If a kernel extension is needed, the script attempts to
download all kernel versions of that extension. Since the OS will load the correct version, it's just simpler that way.
PiCore sometimes has multiple versions. X86 supports core and core64, so we download both versions.

Remember to make the script make it executable:

Code: [Select]

sudo chmod 777 FetchExt.sh
Remember to edit the version and architecture variables to match your system:

Code: [Select]

# User variables ***************************************************************

# Website to download from.
ADDR="http://repo.tinycorelinux.net"

# Tinycore version. Versions always end in  .x , there are no minor version digits.
TC="10.x"

# Processor architecture, current options are  x86  x86_64  armv6  armv7  armv7l  aarch64
ARCH="x86"

# End of user variables ********************************************************
I think the script is fairly well documented if you want to see what's going on. Comments and criticism are welcome.

    [EDIT]: Attachments removed. A link to the current version is in the first post of this thread.  Rich

[GNUser]

This is great, Rich. Thank you.

Just two comments:

1. == is a bashism, which leads to "unexpected operator" errors with the  /bin/sh  shebang (see https://mywiki.wooledge.org/Bashism). Changing every  [ "foo" == "bar" ]  in the script to  [ "foo" = "bar" ]  solves the problem.

2. The three  chown  steps require superuser privileges. It seems the two options are either to run the entire script as superuser or to change the three  chown  commands to  sudo chown  . I prefer doing as little as possible as superuser, so I went with the second option. The downside to my approach is that it is slightly less portable since not every user on every OS has  sudo  installed.

I will keep the script handy. I was using the old version to help me upgrade from one TCL version to the next, but this new version is even better

[Rich]

Hi GNUser

... == is a bashism, which leads to "unexpected operator" errors ...

doctoranonymous reported the same issue in reply #8. I was not able to reproduce the issue (reply #11)
http://forum.tinycorelinux.net/index.php/topic,23034.msg146361.html#msg146361
I did a little searching and I think the correct syntaxes are:
[ "$1" = "info" ]  for strings.
[ $? -eq 0 ]  for integers (equal).
[ $? -ne 0 ]  for integers (not equal).

Could I ask you to change the tests of  $?  to the appropriate integer tests and see if that also fixes the error?

[GNUser]

Hi, Rich. Yes, using the integer syntax also fixes the error.

In your script you can use either the string comparison syntax:
[ "$var" = "string" ]
[ "$var" != "string" ]

Or the integer comparison syntax:
[ $var -eq 0 ]
[ $var -ne 0 ]

The reason you can use either in this script is because the $? variable will always be an integer (return code of the last command). Integers can be compared using integer comparison or string comparison (the shell implicitly converts integers to strings when performing a string comparison). The only thing that doesn't work is the == operator because, although it means the same thing as = in this context, it only exists in bash.

By the way, the integer comparisons would fail if the variable happens to hold a string (including empty string) or if the variable is undefined. For this reason, string comparison operators are generally preferable because they are less likely to error out. I generally only use integer comparison operators when I need one of these operators:
-gt (greater than)
-lt  (less than)
-ge (greater than or equal to)
-le (less than or equal to)

[Rich]

Hi GNUser

Hi, Rich. Yes, using the integer syntax also fixes the error. ...

Thanks for confirming that.

... integer comparisons would fail if the variable happens to hold a string (including empty string) or if the variable is undefined. ...

If my intent is to compare integers, that's how I would want it to behave, because those are all bugs. I think I'll
stick to  -eq  and  -ne  for integers.

... It seems the two options are either to run the entire script as superuser or to change the three  chown  commands to  sudo chown ...

I'm basically in agreement with you. That still leaves systems that request a password for sudo. That could include
systems that request a password for every sudo and those that use a timeout before requesting the password again.

For those situations I'm inclined to tell the user to run the script as root:
Forum error, please see attachment.

[gadget42]

re: bash

reminded of recent:
https://rachelbythebay.com/w/2022/04/05/pipe/

and which referenced previous:
https://rachelbythebay.com/w/2013/08/01/script/

sharing is caring

[gadget42]

one more(re: bash):
https://rachelbythebay.com/w/2022/04/06/text/

"running empty files"...successfully!?!

sharing is caring

[GNUser]

Hi, Rich. I took the liberty to update the script with the following minor changes:

- Removed the == bashism
- Used integer comparison where appropriate (as per your preference)
- Added sudo handling
- Added UID user variable

The reason for adding the UID variable is that some TCL users (such as yours truly) use the user=somebody boot code (in my case it's user=bruno). So while user tc (UID 1001) does exist on my TCL box, my username on TCL is actually bruno (UID 1000). On my foreign Linux box my UID is also 1000. So for me, having the downloaded extensions owned by UID 1000 is much more convenient.

See attached.

[Rich]

Hi GNUser
I already incorporated the integer and sudo changes, as well as a usage message, extremely basic command
line validation, and some other cleanup.

I will roll in your UID addition. Environmental variables use all uppercase, so I'll probably rename that.
I will include your moving chown to a function so I use it in a few other places.
Although the  use_sudo  is not necessary, I'll include it because it's probably good form.

[Rich]

Hi GNUser
Here are new copies of both scripts. I added your changes, more error checking, and a help (-h) screen.
I did some cleanup on the ShowErrors.sh script too.

    [EDIT]: Attachments removed. A link to the current version is in the first post of this thread.  Rich

[gadget42]

re: my earlier semi-related(or not) posts...sigh...one more...but Rob Pike! ftw!

https://rachelbythebay.com/w/2022/04/07/empty/

sharing is caring

20220408-0535am-modified: added "this is not the first mention of Rob Pike on the forum"(go figure...said tongue-in-cheek...lol)

[GNUser]

Hi, Rich. Looks great and works perfectly.

The only fault I can find is purely cosmetic: There are stray -es in Log.txt:

Forum error. See attached.

P.S. The issue is that the behavior of echo's options is notoriously inconsistent across different implementations. printf is a lot more consistent. Solution is in the attachment.

[Rich]

Hi GNUser

... The only fault I can find is purely cosmetic: There are stray -es in Log.txt: ...

Unfortunately, it's not just cosmetic. The ShowErrors.sh  script is basically a state machine and uses the blank
lines as a reset mechanism.

I used echo because it's simple. It didn't occur to me that some versions didn't support escape sequences. I also used
it because it's likely available on all systems. I don't know if that's true of printf.

While it is a good fix, I do want to keep the number of commands required as small and simple as possible just to
minimize the odds of weird stuff like this happening.

Since I was just looking for some extra linefeeds, I'll add a few extra echos in place of the  \n  sequences.