BASH script for package files
I found some 'used' linux isos from a year or so ago. The Puppy ones had the best results. The info from the posts from pan64 and David the H. was helpful. POSIX-compliancy (as well as scripting) has been improved. I used a script from the debian devscripts package (checkbashisms) for check, and actually booted into 3 linux distros with dash and 3 Puppy Linux versions. The Puppy tests proved OK with the removal of -n from cp -r -n. The other distros were not as successful. I did manage to get most out of this script, with the caveat of downloading squashfs-tools and unzip. The cp commands did not bode well. Remember that the results were from a small selection and are not indicative of all possibilities -- watch out for issues - also not bug tested or foolproof
Total revisions: 3
The code is below, ready for copy/paste into a shell scipt.
The script I present (only tested on Puppy 5.2.8) is a simple installer written in BASH and is very simple to use. It is designed to be used as either a quick call for other scripts or directly in a terminal. It supports pet, deb, tar (just -xf)*, sfs, zip*, and pup* formats. It is composed of about 100 lines of code and can be freely modified. It is transparent in the sense that it does not execute scripts - just extract/installs.
*not directly installed, default path = /TEMP, tar path can be modified
It definitely proved useful to me, and can easily be modified, if you know BASH.
Because it was not extensively tested, it may prove buggy, especially in other
Caution: /TEMP is used so if you have /TEMP rename/move it
Usage: '# fexti [argument] [/filename]'
Destination: 'export D="/usr/bin"' (for tar option, else extracts to /TEMP)
# fexti -h displays in more detail - It is relatively silent.
I hope this can be useful to anyone out there.
I copied/pasted the code, using the right click menu in ROX-Filer, and it works for my version of Puppy Linux (Lucid 5.2.8) Again, only tested in that version.
I noticed a couple of minor technical oversights:
1) init variables line: 'export USR=""'
2) couple indentation problems from copy/pasting
1) That can be removed - came from revisions: like the commonality of leaving in past-revision remarks
2) Obvious from past c++ experiences. My coding has most likely become sloppy from lack of use over a long time
I made a second post because I want to keep my original post pristine - acceptable?
if you use variables only inside a shell script you need not use export.
Thanks for the reply. If you look more closely, you will see some variables use export some don't. I used export for 2 purposes:
1) It was the only way I found to get variables passed into functions (global style)
2) Use as an external method "D" for the user to optionally specify destination for tar function
Init variable declaration has also been common practice in the past. In this case, the variable EXT is cleared on init
Code is now fixed. Below is a sample script of how to use it
I have a compiled a list of actual packages that worked with the main script, using the right-click menu of ROX-Filer to 'Set Run action'
I have included the contents of the file that lists what works and what has not been found to work.
Fair warning that the following is around 200 lines, so prepare for a lot of reading/skimming.
An uncomfortably large "mini" ratio of unsuccessful pup files are not successful in this one test. No guarantees.
I see a couple of compatibility problems with the script. There are at least a couple of bash/ksh-specific bits in it.
Remember that if you use #!/bin/sh as the shebang, the script is processed in posix-compatible mode. If your sh-parser is actually bash, then bash-only features are still valid, as long as they don't conflict with posix specifications. But if you use a different shell, like dash, then these lines will generate errors.
Specifically, I noticed the substitution parameter substitution here:
Second are the comparison tests like this:
Alternately, switch the shebang to #!/bin/bash and make it bash-specific. In which case you should take advantage of all its more advanced features like the extended "[[" test keyword.
See here for what to avoid when aiming for posix compatibility:
BTW, since functions run in the current environment, there should never be any need to export anything just for that purpose. But of course it's necessary if any of the external processes executed by the function (or the script) need those values in their environments.
Finally, you need to make sure that all of your variable expansions are properly double-quoted. Those unquoted $D and $EXT variables will result in broken commands if any string stored in them happens to include whitespace or globbing characters.
I also recommend adding tests to ensure that the directories and files actually exist (and are readable/writable, etc.) before use in any of the commands that depend on them.
Thanks for that helpful post. Great points. Feel free to adjust the code to your needs. In reply to your points:
1) I will keep that in mind about using #!/bin/sh. A sed alternate would probably be neater. I never thought about that. (Side note: did you notice the variables spell “Tab" - I did that for chuckles.) I am also not experienced with cross-shell compatibility yet. I skimmed though the wiki you posted and it’s a nice reference.
2) I am excited to report that I found out that it is possible to pass variables regularly to functions. The solution just passed under my nose since day one. I only had to change format to take advantage of it.
3) The double quotes sounds reasonable. Good point.
4) I did explore that idea - to a limited extent. File and directory permissions (r/w included) are somewhat different in this version of Puppy, but I don’t know exactly how. However, that shouldn’t dictate the transfer of permissions stored from extracted files. --> more testing should be done.
All ideas will be considered in future updates with these points in mind while still working as default for Puppy Linux 5.2.8.
Extended version (experimental)
For those who wish to delve into the experimental side, I offer a version that is able to uninstall the same packages it installs.
Very similar to fexti, comes fextiu, which is able to uninstall the more involving packages it installs - those packages that will take more effort than just deleting a folder. (Inspecting the code will show you exactly how.)
I forgot to mention that general uninstalling (especially manually) carries an inherent risk of breaking other installations. (For example, removing a library file for Program B may affect Program A because Program A depends on that library file, which was removed.) This applies to ALL uninstalls regardless of package manager/program.
About 30ish lines of code added, it is untested except for Puppy 5.2.8. It is a little bit more advanced, but I tried to not go too far.
|All times are GMT -5. The time now is 03:30 AM.|