Script to download extensions+dependencies on other Linux distros

[GNUser]

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.

I think  printf  is just as universal as  echo  but I agree with minimizing the number of required commands. Better to just use basic  echo  everywhere than use  echo  in some places and  printf  in others. Eliminating echo's  -e  option will do the trick.

[Rich]

Hi GNUser
OK, fixed the echo commands in FetchExt.sh.

I also fixed a couple issues in ShowErrors.sh:
The read command was swallowing the 2 leading spaces from the lines beginning with Error:.
If the first entry in the Log.txt file was an error, its time stamp was ignored.

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

[GNUser]

Hi, Rich. FetchExt.sh works perfectly now (tested in Devuan where /bin/sh is a symlink to dash). The script has already become indispensable to me--it horrifies me to think of doing a fresh TCL install or a TCL upgrade without it. Thank you so much for putting it together!

P.S. I did not test ShowErrors.sh. FetchExt.sh was written by Rich and tested by GNUser, so I don't expect there will be any errors to show

-----
An echo postmortem:

I can understand a shell programmer having to be mindful of avoiding bashisms when writing a script for a Bourne shell (a.k.a. /bin/sh or sh) implementation. What I will never understand is why the different Bourne shell implementations can't agree to be compatible. echo is a shell built-in, so the issue here was that in TCL's version of sh (BusyBox ash),  echo  needs the  -e  flag to interpret escape sequences. In Devuan's version of sh (dash),  echo  does not have the  -e  option because it interprets escape sequences by default:

Forum error. See attached.

You'd be hard-pressed to find someone who loves shell scripting more than I do, but this kind of pitfall (i.e., ones resulting from compatibility-busting bickering between different  sh  implementations) sure is frustrating.

[Rich]

Hi GNUser

... P.S. I did not test ShowErrors.sh. FetchExt.sh was written by Rich and tested by GNUser, ...

Then I hope you don't mind I included this at the top of the script:

Code: [Select]

#!/bin/sh
# Script to download an extension and its dependencies written by Richard A. Rost July 7,2019
# Special thanks go out to GNUser for his time and effort spent testing and providing
# helpful suggestions and feedback.
#

... so I don't expect there will be any errors to show ...

Always expect the unexpected. We have had the following issues in the repo, all of which will flag an error:
Missing  .md5.txt  file.
Incorrect md5sum in the  .md5.txt  file.
Listed dependency not in the repo.

Which brings me to my final update. I failed to provide the user with a yay or nay when the script finishes.

No errors:

Code: [Select]

tc@E310:~/Scripting/FetchExtensions/tmp/debug$ ./FetchExt.sh PicFormat abook ace-of-penguins acl
......................
OK


Errors:

Code: [Select]

tc@E310:~/Scripting/FetchExtensions/tmp/debug$ ./FetchExt.sh PicFormat abook xyzzy ace-of-penguins acl
......................
One or more errors occurred. See Log.txt after timestamp:
Sun Apr 10 16:43:16 UTC 2022

Seems there's still no xyzzy extension in the repo.

The latest copies are attached here. I will remove the older versions and point the original post to here later on.

[GNUser]

Hi, Rich. The acknowledgement is fine, but it was my pleasure to help. 99% of the time the two of us are involved, the help flows in the other direction...

It's amazing that you found a way to make this script even better!

[Rich]

Hi GNUser
I really appreciate your help. The goal of this update was to make the script as painless to use as possible. Thanks to
your efforts, I think we may have accomplished that.

[zharr]

So I didn't know this script existed and made my own script, including flashing and other setup, essentially so I can use one command to set up a repeatable image including all dependencies, wifi & ssh, custom program sources, etc.
It is less a ready-to-use script and more of a setup-once-and-forget kinda thing if you expect to distribute something that uses a tinyCore image or just want your setup to be repeatable.
Note: It's made for piCore, so you HAVE to edit your sources/kernel versions and extensions beforehand, and remove some custom RaspberryPi-specific config.
I posted the script here:
http://forum.tinycorelinux.net/index.php/topic,25760.0.html
Includes a custom wifi script so it connects to the best available known wifi.
With this I can set up a new SD card with everything I need and work on it over SSH within a minute, no matter where I am (office, home, etc.), without needing a keyboard and monitor.

[tacpilot]

I had to split this across multiple posts because of the server error issue plaguing us all.

Though sed supports using most anything as a separator, unless you have some instance that
requires using something different, I would stick to using "/". This will keep your coding habits
inline with standard REGEX syntax across languages, and makes code easier to read when
used in a long line of command piping.

[tacpilot]

Because of the extended features of bash, I so much prefer coding in bash over sh. However,
portability with shared scripts becomes and issue. With /bin/sh being linked to numerous shell
interpreter ie.. ash,dash, busybox , ... , the conformity guidelines revolve around being POSIX
compliant.

Coding habits become most important in collaborative environments, and accepted standards
become demanded. Its just good habits to get into.

[tacpilot]

There are numerous tools out there to help check for such things. Some you can run locally
and some sites you can post to.

Here is one such site that will check your code...
https://www.shellcheck.net/

Hope This Helps

[zharr]

Thank you very much tacpilot - as you might have guessed I am not that proficient in shell programming.
Though that means I can't use [[ ]] either, as it is not part of posix sh, right? Would you really recommend me to switch that?
I expect this script to be run on a Linux host, though even busybox supports [[ ]], so it should not be a big deal to use it right?
But yeah, making it compatible with tinyCore sounds like a good idea long term, so even people only using tinyCore can use it.
Actually sounds like a decent idea for my project, for people that want to build custom images for my embedded project but don't use linux, I can provide a tinyCore image to boot to that can be used to set up the embedded piCore image - genius!

[tacpilot]

Would you really recommend me to switch that?

The language you choose depends upon your target audience. The reason
basic shells are often coded to is for portability, or with TinyCore is for size.
Bash was evolved to expand the features avail for shell scripting. Things
like asociative arrays and REGEX features are nice to have access to in
a language. In the past bash was not avail for all operating systems. Now
days bash can be found everywhere.

It sounds like your code base is functioning as you envisioned. This means
you accomplished your goal without bash feature sets. This is a good thing
for portability, so don't feel like you have to change. Since it works, I would
just use the code checkers, follow their suggestions, and tweak your code
to become more inline with the standards. If nothing else, this would be an
educational experience in making clean code.

Since your target audience is for the TinyCore community, portability isn't really
an issue. It sounds like you plan to use this on a desktop system, and not some
small form factor embedded system. This means size shouldn't be an issue. So
if you want to switch, bash.tcz and its dependencies are avail in the repo for a
combined size of about 840K.

I can provide a tinyCore image to boot to that can be used to set up the embedded piCore image

Now that is the power and beauty of TC.

It would be straight forward to create your own TC package for this. If you choose to
switch to bash, then just include it and its dependencies as requirements for your
FetchExt.tcz package.