Tiny Core Linux
General TC => Programming & Scripting - Unofficial => Topic started by: jpeters on May 27, 2009, 10:25:10 PM
-
Allows reinstallation or download of tcz* or tce* extensions; duplicate menu issues get fixed on reboot. (note: reinstallation overwrites the loop and tce.menu, so it only looks like there are two copies)
example with xonclock:
tc@box:~$ sudo rm /usr/local/tce.installed/xonclock
Appsbrowser will now reinstall/download
-
close app and unmount
example unmounting xonclock.tcz:
@box:~$ sudo umount -d /tmp/tcloop/xonclock
Appsbrowser will now reinstall.
I thought Jason had said there could be problems with this approach and that the tcz-uninstall tool was the preferred way to perform a tcz update.
-
close app and unmount
example unmounting xonclock.tcz:
@box:~$ sudo umount -d /tmp/tcloop/xonclock
Appsbrowser will now reinstall.
I thought Jason had said there could be problems with this approach and that the tcz-uninstall tool was the preferred way to perform a tcz update.
I'm still testing it out. I found a better way to get what I wanted, however, and edited the original post.
By removing /usr/local/tce.installed/app, I can download or reinstall both tce* and tcz* extensions
-
After testing a while., this seems to work. Menus will adjust after rebooting. If saved as "update" run
"update app" without extension {eg, "update coreutils") . Then use appsbrowser to reinstall. Works for
both tce and tcz updates.
example....set path to your own tce/tcz directory:
#!/bin/ash
sudo rm /usr/local/tce.installed/$1
[ -e /mnt/hda3/tcZ/${1} ]; then sudo rm /mnt/hda3/tcZ/${1}.* &>/dev/null
-
Yes, it is probably better to use the tcz-uninstall tool since it will remove more things that may not be overwritten by loading another extension.
-
Yes, it is probably better to use the tcz-uninstall tool since it will remove more things that may not be overwritten by loading another extension.
We need a way to update tce as well as tcz. From what I've tested, the tcloop gets overwritten, so the app seems to reinstall correctly. This approach doesn't mess with the deps, which is just fine with me, and I would guess that configuration files are generated from within the program. An uninstall program that removes all the files doesn't exist.
-
tcloop is mounted. I was namely referring to the likelyhood of broken leftover links.
There is also tce-uninstall.
-
tcloop is mounted. I was namely referring to the likelyhood of broken leftover links.
There is also tce-uninstall.
I haven't had any problems, but I suppose worst case scenario is that someone could reboot.
btw/ my primary interest is the ability to download updates into my tcz directory without first having to manually delete, reboot, and then reinstall. If the app happens to be something being used, like jwm.tcz, it's even more complicated. With the update script, I can reinstall even if the app is running.
-
Updating extensions really is as simple as using tcz/tce-uninstall to remove the app, and then reinstalling an updated version with the appbrowser or the command line. Rebooting is not necessary (though always a choice), but uninstalling a window manager and using another one during the same session would of course require more than just the act of uninstalling one and installing another. In that case rebooting to use the new WM would be the easiest for most.
Tce/tcz-uninstall does remove all the files that are contained in an extension. Config files and directories that apps create in /home I believe should be left up to the user as whether to remove, never to be automated. And temporary files created in /tmp and /var do no harm being left after an uninstall until next reboot. Almost no package manager deals with such temporary files to my knowledge anyway. But those files can be placed as empty writable files in the extension if their removal upon uninstall is important. Or they could simply be manually deleted.
Whether one deletes an extension from the tce directory and reboots, or uninstalls the app is personal preference. Both will get you there. Of course, tcz's would ideally be unmounted before being deleted but that is of no issue if one is about to reboot anyway.
-
If the app happens to be something being used, like jwm.tcz, it's even more complicated. With the update script, I can reinstall even if the app is running.
Ah, if that's your primary concern, you could ask for that feature for tcz-uninstall. Currently, it has an explicit check to halt on that scenario iirc.
-
I just used 'update tce-unstall' after
tc@box:/mnt/hda3/tcZ2$ tce-uninstall
Retrieving installation info. Please be patient.
I did wait the required 30 minutes.. :D
edit: The second download worked. Glad I had "update" to get it, though :)
Whether one deletes an extension from the tce directory and reboots, or uninstalls the app is personal preference. Both will get you there. Of course, tcz's would ideally be unmounted before being deleted but that is of no issue if one is about to reboot anyway.
I like to utilize the advantages of PPR to every extent possible, so will choose a two line script for something like updating.
-
"update" script with adapted menu and wbar fixes from tcz-uninstall Usage: "update APP" {eg, "update gnumeric" ); reinstall with appbrowser ( or add wget to script ).
-
"update" script with wget and tce-dir. USAGE: "update APP" (eg, "update gnumeric"). note: scripts finds previously installed extension (eg, tce, tcel, tcz, etc.) & re-installs [testing]
edit: found a simpler way finding APP
-
Added an exit, shortened some script, changed a few tests that weren't working correctly.
edit: moved exit to better location in script.
-
Added fix for bug in tce-load script
-
Your update script is getting better all the time. How about taking a crack at adding the dependencies as well.
-
It already does, since "tce-load $APP wget install" works like appbrowser. If you want it to update a dep that's already installed, you would run "update" on that particular extension.
-
Yes I got that. What I meant was to go to the next level and check the deps to see if they have changed and then reinstall them if need be. In doing so the application including it's deps would be updated. Now that would be heroic.
-
Yes I got that. What I meant was to go to the next level and check the deps to see if they have changed and then reinstall them if need be. In doing so the application including it's deps would be updated. Now that would be heroic.
That would involve that whole issue of recording install dates, etc., etc., noted in another thread. Also, I like having the choice of what and what not to update.
-
I get your point. Flexibility has many advantages over automation. I was just thinking there has been a lot of good work by Florian, jls_legalize and you on this subject. Putting all three of your contributions together would be great. I would do it but I'm not up to your level yet.
from Florian
#!/bin/sh
# computes a md5sum of the tce/tcz extension file passed as a parameter,
# and compares it with the md5 checksum stored on the online repository.
# this for instance allows to detect if a new version of an extension
# is available.
MD5=/tmp/$(basename $0)_$$.md5
clean() { rm -f $MD5 $MD5.server 2>/dev/null ; }
die() { echo "$1"; clean; exit 1; }
. /etc/init.d/tc-functions
[ $# = 1 ] || die "Usage: $(basename $0) EXTENSION"
[ -f "$1" ] || die "$1: no such file"
MIRROR=`awk '/Mirror/ {print $2}' /opt/.tcrc`
PROTOCOL=`awk '/Protocol/ {print $2}' /opt/.tcrc`
stringinstring .tce "$1" && REPO="tce"
stringinstring .tcz "$1" && REPO="tcz"
[ -z $REPO ] && die "$1: not a tce or tcz extension file"
URL="$PROTOCOL"://"$MIRROR"/"$REPO"/"$1"
trap clean SIGHUP SIGINT SIGTERM
md5sum "$1" > $MD5
wget -q "$URL.md5.txt" -O $MD5.server || die "can't fetch checksum from server"
diff $MD5 $MD5.server > /dev/null || die "differs from server"
clean
jls_legalize
"if u launch this script from a dir containg extensions and u save the script made above by florian tce-chk.sh
my script elencates at the end all the extensions that are not up to date."
#!/bin/sh
#controlla se tutte le estensioni presenti directory corrente sono aggiornate
#checks if all the extensions in the current dir are uptodate
#jls_legalze unsenepopiu at tin dot it
FILETMP=`mktemp`
for FILE in *; do
if [ -f $FILE ]; then
estensione=${FILE##*.}
if [ $estensione = tce ] || [ $estensione = tcz ] || [ $estensione = tcel ] || [ $estensione = tczl ] || [ $estensione = tcem ] || [ $estensione = tczm ] || [ $estensione = tcelm ] || [ $estensione = tczlm ]; then
if [ `tce-chk.sh $FILE` ]; then
echo "ok"
else
echo "errori:"
echo $FILE >> $FILETMP
fi
fi
fi
done
-
I was thinking along similar lines after your previous post. Download the md5.txt files associated with the apps in the tcz folder, and do a md5 -c with them. The one's that FAIL need updating.
-
Bug fix (wasn't updating some files with name conflicts)
Edit: check-update script is listed in a separate thread
-
I was surprised after running check-update that about 10 extensions required updating. The update script completed the work in about a minute. To be completely safe, though, I might reboot at some point :)
-
I was surprised after running check-update that about 10 extensions required updating. The update script completed the work in about a minute. To be completely safe, though, I might reboot at some point :)
Great progress! Thanks for the contributions to tinycore.
-
I was surprised after running check-update that about 10 extensions required updating. The update script completed the work in about a minute. To be completely safe, though, I might reboot at some point :)
Great progress! Thanks for the contributions to tinycore.
Hope that works for now. Given the time it takes to download & check md5's, keeping the two scripts separate seems best.
-
Adds check-update option "update -c"; help "update --help"; version "update --version". If {tcz*,tce*} ext mistakingly included, opens help menu. (for TC_2)
Edit: Added cleanup for check-update
Edit2: Fixed bug...relocated an exit
-
(for TC_2)
Update includes switches:
"update -c" checks tce dir for update candidates
"update -d APP" (eg, "update -d gnumeric") checks dependencies for update candidates
"update --help"
"update --version"
"update APP" Updates (eg "update gnumeric" )
-
tinycore 2.0:
1)emelfm2.tcz don't start after intalling by appbrowser....
emelfm.tcz works great!
2)leafpad don't work.
I think, may be dependencies of leafpad and emelfm2 doesn't sutisfied.
-
I tried both with no problem. The dependencies should already be loaded after installing with appbrowser, although wget install would load them if they weren't. You might try "update -d leafpad" or emelfm2 to check on dependencies. Did you type "update leafpad" (not leafpad.tcz)? Does it require a reboot to work (so far, I haven't had to). note: the update script works only for extensions that have been previously installed...so dependencies should already be loaded and presumably working.
-
sh: update: not found
sh: upgrate: not found
???
-
sh: update: not found
sh: upgrate: not found
???
Did you name your script "update" and give it exec priviledges (eg "sudo chmod +x /update" )?
edit: At some point, I'll probably submit as an extension.
edit: oh...sorry about the typo in previous post....should be "update leafpad"
-
Added "update -v" , views tce directory.
-
Added graphical interface. USAGE: 'update -g'
-
The script is getting big, soon it'll be smaller as a compiled version ;)
-
The script is getting big, soon it'll be smaller as a compiled version ;)
I submitted the present 4K version. omitting the "update -na" feature that plays the
National Anthem while doing file checks. :D
(note to Jason:; I'm only joking)
-
Actually, I may consider adding an option of --with-music to tce-uninstall that would play songs in alphabetical order in, say, the /usr/local/share/music directory. That would help pass the time spent waiting for the list files to download. The number of songs you would want to place in that directory would be relative to the amount of tce's you have installed. But that would add a dependency on mpg123, so I may leave it out.
(Humor used here as well) :)
-
In the unlikely case that /usr/local/share/music is empty, it should then proceed to download Top 500 Trance Remixes, at a priority higher than the update files no less. The longer wait would obviously be worth it, because users can grasp the excitement in seeing music trickle in, and after that, continue to listen while the lists download.
Of course there should be the hidden option for us devs that, instead of downloading, mounts Jason's mp3 collection over NFS :D
-
:D
BTW/ Jason... if you want to improve the visual experience while listening to all that great music,
you could dump the dialog --title (line 126 in tce-uninstall, line 161 in tcz-uninstall) , since it duplicates the menu txt.
-
Am I correct in understanding that this script recalculates the md5sum for each extension on my local machine, and then compares the answer with the "official" checksum over at ibiblio.org? Unfortunately, I need a way to verify that the contents of my tce directory have not been tampered with. The script looks perfect for this ... but I'm feeling a bit paranoid at the moment, so I want to be extra sure I understand its operation. Thanks.
-
'update -c' downloads new md5sum files for everything in your tce dir, and then tests the extensions.
edit: downloads are to /tmp/md5 which is later deleted....so no danger. The complete report is in /tmp/update-check, and a failure report redirected to your terminal.
-
Super. I endorse your designation as "Hero Member". Thanks again.
-
Unfortunately, my submission of the update extension has been rejected with the explanation that only their own submissions (the"team") are acceptable in the repos. I find this amusing, but sufficient reason for me to move on and end any further contributions to tc. Thanks.
-
The team has discussed the issue of submitted extensions that are scripts and it was decided that standalone scripts should be made available in the forum. In most any distro, there is a section in the forum just for scripts and coding as opposed to the scripts or coding becoming a package. In fact, I had decided yesterday to move my uninstall scripts out of the repo and will make them available in the forum for several reasons. Mainly because uninstalling is not an official method of TC, as well as not all WM's are supported so they are incomplete. A script existing in the forum does not mean it is of lesser value, it is just simply where scripts are best kept.
Scripts in the forum are very maintainable by their owner without having to wait for an update to be processed. This would especially be good for a script that downloads things from third party sources. They can be improved upon by others in the community and improvements by others can be posted, and it will all be available in one place and at once.
It is community's contributions that help make TC what it is, and we value all of those contributions. Please understand the decision to keep contributed scripts in the forum and keep the repo for applications and library packages.
-
The team has discussed the issue of submitted extensions that are scripts and it was decided that standalone scripts should be made available in the forum. In most any distro, there is a section in the forum just for scripts and coding as opposed to the scripts or coding becoming a package. In fact, I had decided yesterday to move my uninstall scripts out of the repo and will make them available in the forum for several reasons. Mainly because uninstalling is not an official method of TC, as well as not all WM's are supported so they are incomplete. A script existing in the forum does not mean it is of lesser value, it is just simply where scripts are best kept.
Scripts in the forum are very maintainable by their owner without having to wait for an update to be processed. This would especially be good for a script that downloads things from third party sources. They can be improved upon by others in the community and improvements by others can be posted, and it will all be available in one place and at once.
It is community's contributions that help make TC what it is, and we value all of those contributions. Please understand the decision to keep contributed scripts in the forum and keep the repo for applications and library packages.
What does in the forum mean? Is there a download repository in the forum for scripts? If not there should be if they can't be placed in the extensions repository. I hope you are not suggesting they are buried in post messages helter skelter.
-
Community contributed scripts being posted and developed in the forum is the norm in the Linux world. There will be accommodation for contributed scripts and scripted utilities in the forum. Bear in mind that this distro is still in it's early stages and things are changing and growing. Sometimes decisions have to be made as we go and a solution will be arrived at.
-
All utilities start out as scripts. Until it's turned into an extension, it's of little use to the general community. Extensions can continue to be developed by the author....that's why there's a change-log.
-
I really am caught between a rock and a hard place on this issue. Scripts that exist in application extensions do simple things like stop or start a service, or other such things that are easy to look over and debug in the case of an issue. Those are generally safe even in the case of a bug in them, and their sanity can be confirmed by a quick glance. And the for programs themselves that we submit, we are compiling known code that many other people out there are using.
Such is not the case with a complex utility script that do things like install or remove packages, or format partitions, or stuff like that. These scripts have to be done just right or a lot of damage could be done with their use. Any of my such scripts of mine that I have posted to the repo have been discussed with the team and has their testing and approval of concept. I cannot and do not post any of my own scripted stuff without the team, and namely Robert's, blessing. In other words there is a QA and testing process that has to occur before a system changing utility script is posted to the repo for widespread use.
We are probably the most open distro there is when it comes to community involvement, and we like it that way. But we as the developers are responsible for what is available for users to download and use from the repo. So for me to accept these scripts as extensions they would have to involve my testing and then my feedback to the submitter as to what needs to be done if the script is not sound. It would demand a lot of time from both me and the submitter. And I doubt that kind of meddling would be taken well. So whichever path I took on this issue there were going to be hurt feelings.
But scripts that are posted in the forum are free for folks to develop and use as they wish, and free from my involvement. I think in the long run folks will like it better that way.
-
Update can download md5 files for deps or extensions in the tce dir. to /tmp/md5 (which it later deletes) It performs a md5sum check, and files a report in the /tmp directory. Other than that, it
wgets a selected extension using tce-load wget install. Does any of that sound overly risky? (sure seems a lot less risky then tce-uninstall)
Update has become one of my most used apps...if there's no interest in it, that's fine with me. I can check my tce-dir for update candidates and update a batch of extensions in seconds.
Regarding leaving things in tips & tricks.....as far as "update" is concerned, nobody is going to read through 45+ posts to figure out what to copy....if they can find it to begin with after it's buried. For most simple scripts, no extension would be necessary.
-
It is not that there is no interest in updating apps, or in your script. And I agree that for simple scripts no extension would be necessary. And I have not said that updating apps is not a good idea.
But while we are discussing this, let me point out what I see in your script that can leave a user with a broken system, at least broken extensions though not base. First, you are not umounting the tcz file itself before deleting it. That may not be itself cause breakage in extensions, but it is not a good practice. What I see that will sooner or later cause extension breakage is the fact that your script does not remove the symlinks from the old extension before loading the new one. When a tcz is loaded, it does not overwrite existing files or symlinks. Say for example you updated gtk2.tczl to version 2.14.8 from 2.14.7. When you run your update script, none of the existing symlinks would have been overwritten. So the file ./usr/local/lib/libgtk-x11-2.0.so would still be a symlink pointing to ./usr/local/lib/libgtk-x11-2.0.so.0.1400.7 when that is an old, dangling symlink that points to a no longer existing file. The new lib would be /usr/local/lib/libgtk-x11-2.0.so.0.1400.8 but the .so file will not point to it. Therefore gtk2 apps would no longer work.
It is not that I care that tcz-uninstall was not called on in this script, but the removing of symlinks in the system and the umonting of the tcz file before deletion is needed.
And I agree that hunting through many posts to find the latest version of a script is not ideal. I do not have a problem investing time to work with people in honing scripts for the community to use. And if we did accept system changing scripts in the repo they would need to start in the "programming and scripting" section of the forum, develop and mature there with team input, and then be candidates for uploading. It is great we have a community that invests their time in developing extensions and utilities to further TC. I would like to help encourage that and have a process that facilitates the development of scripted utilities and tools. Like mentioned before, this distro is young and things are still evolving.
There are several criteria that a script should meet for it to be a general use script in TC. One is that no hard coded paths are to be used, the variables defined in the system should be used instead. In this script I see a hard coded ftp download directory when it should reflect the mirror chosen at the control panel. One tricky part that my uninstall scripts also do not cover is the handling of WM menus besides JWM. But that can come in time as those details settle, and there is a tool in the works that will help with that. A script needs to work across all modes of operation or be confined to a single defined one. Yours of course is for PPR/TCZ. And, obviously, the utility should not leave a user with broken extensions or worse put a user at risk for lost personal data.
I agree that tce-uninstall is somewhat "out there". I was advised against it but I pushed for having it. There is a design flaw in it that is not correctable, hence my decision to retire it.
-
The idea behind 'update' intentionally was to make it simple and fast, so it avoids
elaborate uninstall features already available in tcz-uninstall. Once in the tce directory, that issue presumably would be handled after a reboot. For all apps in my tce directory, things worked without rebooting (I consider that to be a fringe benefit). I added the fix to menus and icons as an afterthought when Robert made mention. Still, as noted, I can update a dozen extensions in about a minute. If I had to reboot to get a link to work, that's only another 15 seconds.
The path used for downloading md5 files is "ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/" Is there a better way to script this? It seems to work well.
I'm not aware of anything in 'update' that would lead to file corruption or loss of data, so don't know what you're referring to on that. Update uses tce-load wget install. It deletes the selected extension from the tce dir so that it can be installed, which is what I would have to do manually anyway for wget to install a new copy.
I appreciate your comments. I posted everything about update in the thread, and after about 1000+ views, have not received feedback about problems other than the possible links issue noted in your post.
-
The data loss I was referring to was not directed at this utility but as a general condition to avoid. It would be possitiblithy with other operations that are not part of update.
The deletion of old symlinks takes an almost unnoticable amount of time with find and xargs, and would really be necessary for a clean update of apps. If rebooting were required, then all that really would have to happen is a removal of the *.tcz* files in the tce directory, the rest would be good on a reboot.
There are system variables for the mirrors, and I can list them when I get home to TC.
That way a user would be using his selected appbrowser mirror.
At work, have to go.
-
I see...you want to read the /Mirror/ path from /opt/.tcrc instead of writing it in directly. OK
note: That only was for the md5.txt downloads. The script already uses /opt/.tcrc for the install:
case $APP in
*.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
*.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac
tce-load $APP wget install
-
Ok, I see.
-
use /MIRROR/ for md5 download
-
On the subject of removing the symlinks, the boost extension has 6737 symlinks created. It takes a quarter of a second to remove them all with find and xargs on a 2.6ghz machine. That is not bad overhead even with the largest extension (in number of files). Also, a lazy umount (umount -l) of the tcz would make things good as deleting a mounted file is not the best practice. This would prevent the need for rebooting in almost any circumstance.
-
ok...this umounts -ld & deletes symlinks.
-
I admit I may be an unusual user but I count on being able to uninstall apps without a reboot and I count on tce-uninstall to remove the app correctly without having to worry about residual effects. Any remaining files that tce-uninstall leaves behind can be removed with a wrapper script. However, I do see the merits in the update script. It does serve a valuable purpose. It would seem to me these two scripts could be combined in some way to produce the best of both worlds. I would love to see the update script offer the user the choice of using the comprehensive tce-uninstall or the quick and dirty uninstall. How about it guys?
-
At this point, 'update' shouldn't need a reboot. I use tcz-uninstall for a different purpose, like when I'm trying out a new ext and need to keep uninstalling/reinstalling. Update only works when you want to replace an existing app with a newer version that's in the repos. Given all the related features (update-check, etc), it might be best to leave it as its own tool. If you've already run tcz-uninstall, might as well just run appbrowser. In fact, 'update' wouldn't work at that point, because the extension needs to already exist on your computer. One more reason....'update' works for all extensions, not just tcz, so you'd be talking about adding tce-uninstall as well (....uh...no thanks.... :) )
-
Although I removed symlinks, I still have a question as to why that's necessary when updating vs/ uninstalling. Since it's only a link, it will simply connect to an updated file, so shouldn't have to be deleted and re-written. The only problem I could see would be a previous link that is no longer used, which wouldn't effect functioning of the updated app at all....and the dead link would remove itself after the next reboot. Maybe I'm missing something...
Edit: I guess it doesn't....I'll try umounting first and see if that works.
-
After testing, I found as long as the extension was umounted, the links correctly displayed the updated content, as expected, so extensions would work without deleting the symlinks. Deleting them simply removes any that are no longer used, which would probably be rare for updated apps, and in any case removed after rebooting. (although no harm in removing them, either)
-
Such is not the case with a complex utility script that do things like install or remove packages, or format partitions, or stuff like that. These scripts have to be done just right or a lot of damage could be done with their use. Any of my such scripts of mine that I have posted to the repo have been discussed with the team and has their testing and approval of concept. I cannot and do not post any of my own scripted stuff without the team, and namely Robert's, blessing. In other words there is a QA and testing process that has to occur before a system changing utility script is posted to the repo for widespread use.
TC is being developed very quickly, which is fantastic, but a nightmare to keep up with it all. Tonight I decided to upgrade to the latest, but realised that I had no clue which of my tce and tcz extensions needed upgraded. With dialup (which is all I have) it is a major job having to re-download everything so some auto-checking upgrade script is an absolute essential in my opinion. Admittedly, I didn't use jpeters upgrade script on this occasion, but instead spent hours actually re-downloading everything by hand. But that was unsatisfactory - next time I want to use the script!
However, it is a relatively complex script, and I am scared to use it because even the best programmer can easily leave a bug or two, which could cause a major disaster! So, on one hand, I absolutely agree with JasonW that the TC core team need to carefully vet any such script, and its nature makes that quite a lot of work - but I do feel that it is really an essential utility for a distribution such as TC which comes in the form of a "mechano set" for building complex configurations out of many parts - you NEED an upgrade facility for such a distribution, surely?
I also think it is a great pity if the tce or tcz uninstall scripts are to be "retired" such that they are no longer available. What a waste of your work! I don't agree that such a script necessarily has to be able to deal with ALL tc modes of operation - nice if it can be so general purpose, but it's useful anyway, for whatever mode it works with. The users just need to be educated about when it can be used and for what modes, and when it shouldn't be. Surely all the wm menu-related issues will soon settle down and make it worth revising the uninstall scripts at this early stage in the development of TC.
I really do think that the only thing I'm not quite satisfied with when it comes to using TC is that, by default, appbrowser doesn't allow me to re-install an already installed extension (with an updated version). First the user needs to uninstall the old extension - so that IS a vital system facility that badly needs to be provided. That's my opinion anyway. I can assure you that jpeters isn't the only user who felt that a facility for upgrading existing extensions was needed. I also had that feeling and was glad to notice work was being done on it. But, yes, upgrade is a relatively complex script and, like all such system-level scripts, a potentially dangerous one - it thus NEEDS to be designed either by the TC core development team or under their tight control in terms of collaboration and testing. I also agree that it's not satisfactory, to leave symlinks hanging around, whether or not such stray links seem to have no adverse effects - such script behaviour is just inviting unforeseen potential trouble. Having said all that, jpeters work is to be applauded and encouraged - I didn't see anyone else trying to provided the functionality of "upgrade" and somebody needed to!
Summary... I vote strongly for an "upgrade of existing extensions" facility, which really should be provided with the TC core system in my opinion (and hence rigorously designed and tested at that level). I can' say one way or the other if jpeters utility is the best way to provide that facility or not, but "retiring" any such script (or hiding them away in the depths of the forum) is not the way to go for such an important omission in what TC core currently offers.
-
A very conservative and safe upgrade script is currently being tested by TC team.
My plan is for it to be available in the final 2.1 release.
-
The update script is safe, and works well for checking updates and for updating apps. Safety was never an issue.....some people felt it didn't do enough "deleting" , so I added features so that you don't need to reboot. It doesn't screw with deps unless you ask it to, but will tell you what deps need updating. That's one of the reasons it doesn't break your system.
-
We will never agree on this. I am of the opinion that one should not attempt to upgrade extensions that are being used. A simple method will be made available to upgrade all extension be they tce or tcz in batch fashion.
-
Very conservative and very safe sounds good to me for this kind of purpose. I'm glad to hear that is being worked on. I can understand jpeters' feelings though. Nevertheless, such a script is clearly core functionality and needs to be carefully designed and tested at that level regardless of how good or bad any user-designed and developed scripts might be. A trusted repository works on the basis of careful testing and vetting.
As far as I see it, open source just means that the source code is published, and that anyone can fork a project, but it doesn't, I realise, infer that users can insist on their code being included in official repos (especially when the code is concerned with core functionality). But it would be good to have "unofficial, or "user-repos" too, so that general users of TC can share their own enhancements, at user risk, some of which might (or might not) later be adopted and incorporated into the official core. That's just how these things work, but then, I didn't start the TC project - I'm just a user, but hope that I sometimes manage to contribute something useful.
Anyway, until something else is provided, I'm planning to use jpeters script, and might even modify it for my own specialised purposes - which is another reason that easily located user-shared scripts are so handy.
-
We will never agree on this. I am of the opinion that one should not attempt to upgrade extensions that are being used. A simple method will be made available to upgrade all extension be they tce or tcz in batch fashion.
Sorry, but this is the first I've heard that there was a disagreement. I think I responded to every suggestion on the thread. The tcz extensions are umounted before being updated, but that was only so that rebooting would be unnecessary. (can you be "using" an extension after it is umounted? )
edit: I wrote tce-remove in case I wanted to delete tce.list files before reinstalling, but from the testing I've done, it doesn't seem necessary.
As anyone knows who has looked at the script, 'update' works for both tce and tcz extensions. Doing 'batch' would be trivial, since it only takes about 60 seconds to update 10 extensions with the advantage of being able to choose what you want updated (adding automatic functions would be simple...personally I don't like them) . I don't think this script could get much simpler....I included a gui
-
Added option "update -f APP" (eg "update -f gnumeric). Checks individual extension. As always, include
only base name, since script will check tce dir for appropriate file. "update -d APP" checks deps, and "update -c" checks entire /tce dir . Update script updates and checks all extensions (tce/tcz). To update: "update APP" (eg., "update gnumeric") or "update -g" for gui. Help: "update --help"
note: very simple & safe; no automatic deleting/installing; tcz unmounted before update; works without rebooting.
Edit: Save script as "update" and place in $PATH (or graphics won't work).
-
edit: removed extra "/" in 'update -d' tcedir path. (crept in after using /mirror/ )
edit2: more specific find function in "update -f"
edit3: reset background after update (necessary for tc_2.1 )
-
added wbar.sh to reset wbar at end of script. Needed with with tc_2.1
note: sometimes it's necessary to run wbar.sh several times, or you can restart X (alt backspace;startx) to fix the wbar issue. This same issue now appears when loading local extensions.
edit: fixed
-
Fix so that compiletc, etc, updates (was going to help menu..needed better grep command).
edit: wbar issue occurs only when wbar covered with another window when updating (using jwm)
-
...Included a better dependency search (eg "update -d APP") that reads the dep file, but matches the extensions to those (if present) in the TCE dir. I found this useful in checking for missing or corrupted dependencies, in addition to finding those that need updating.
-
added "update -i {tcz,tce} ". Downloads md5.txt files to /tmp/db-md5 and lists extensions in
Dialogue for new install. ( note: database can be copied for fast installs).
edit: Set path to persistent database at top of script.
edit: Fixed bug in "update -c" (extra char just in this version).
edit: Fix wbar only if using.
edit: Put controls around main wbar code (for those like myself who no longer use wbar).
-
Updated for Tinycore_2.3
-
Added update support for tcz to ram. Checks for file in tcz2ram.lst, and installs to ram if present. (ex "update aalib")
note: script uses wget.tcz (for update -i )
-
New option: "update -ix {tce/tcz}" : Quickly loads existing database for new install
Use "update -i {tce/tcz}" for building new or adding to existing database (set path
at top of script). Installs new database at /tmp/db-md5)
uses wget.tcz extension ( uses noclobber option for adding to existing database)
-
New option: "update -cx" Uses existing database for quick update check of tce directory.
To build local database, use "update -i {tce,tce} and set path to DB at top of script.
Tutorial:
[removed due to policy]
-
Fixed bug in "update -d ..." (checks deps).
-
updated for tc_2.3.1
new options for tc_2.3:
-ir installs tcz to ram (creates new or adds to persistent database)
-irx installs tcz to ram using persistent database (fast loading)
-rem [APP]: removes APP from tce directory, umounts tcz; Dialog or [CLI]
Lists (but doesn't remove) deps; removes symlinks;
allows for reinstall with menu/icon fixes.
Improved -g (Dialog) so that update no longer needs to be in PATH
Persistent DB (if it exists) now gets updated with all -c, -d, and -f checks.
Fixed -d dependency checks
note: set correct path to DB at top of script (or comment out with leading "#")
update -i requires wget.tcz/e
Tutorial:
[removed due to policy]
-
new options for tc_2.3:
-ir installs tcz to ram (creates new or adds to persistent database)
-irx installs tcz to ram using persistent database (fast loading)
-rem [APP]: removes APP from tce directory, umounts tcz; Dialog or [CLI]
Lists (but doesn't remove) deps; removes symlinks;
allows for reinstall with menu/icon fixes.
Improved -g (Dialog) so that update no longer needs to be in PATH
Persistent DB (if it exists) now gets updated with all -c, -d, and -f checks.
You have created quite a master piece. Thanks for the effort. However, when I go to use the script I find that I can't remember all the options usage rules. Would it be possible to create a terminal command menu to simplify operation?
-
There's an "update --help" Is that enough ?
-
added permission error fix.
-d wasn't checking...fixed.
-
Update Tutorial
[removed due to policy]
-
Updated for TC_2.3.1
improved code for dependency checks
-
Added permission bug fixes for tce-load -i -r -w
-
Added options -dep, -list, and -info. Update does a search for the file, lists the downloaded results, and reads them. Thus "update -info gnumeric" will list "gnumeric.tcz.info" and read it to terminal. "update -info vim" will list:
vim-7.2-bin.tcz.info vim_7.2.245.tcz.info
vim-7.2-docs.tcz.info vimtutor.tcz.info
and then cat into one file to terminal.
Also added: update -vx. This lists the files from the persistent database if present.
EDIT: improved report code for easier viewing of multiple files
EDIT: fixed misplace "fi" in permission check.
Tutorial:
[removed due to policy]
-
For version_2.4rc1:
Eliminates use of tce directory; uses "update -i", "update -ix" (no {tce/tcz}) for non-ram tcz installs.
Added options:
-inf Reads info file using BROWSER and database if present. (set at top of script)
-dp Reads dep files using BROWSER and database if present.
-ls Reads list files using BROWSER and database if present.
example: "update -inf gnumeric"
If no browser or database , options act as shortcut to -info, -dep, -list option (downloads file from rep).
Recommended: links browser. VERY FAST
Uses wget.tcz
"update -vx" will view the database.
Added a few more tests:
Tests if trying to install a tce
Tests if an update fails
Added search option -s
Tutorial:
[removed due to policy]
-
bug fix: had misplaced a "fi" in the permission check, so wasn't updating correctly
-
bug fix: fixed multi-call error when using BROWSER for viewing .info, dep, .list files.
-
Changed new options to shortcuts that automatically read from browser if present. (less typing).
-
Added an exit, shortened some script, changed a few tests that weren't working correctly.
edit: moved exit to better location in script.
Now that tc has gone through many revisions, isn't it true that the latest extension revision might not work with previous versions of tc. I wonder if there should be a check of some kind that warns about this potential mismatch before the update takes place.
-
There is a related question. Is there any reason to keep a previous version instead of moving to the latest stable release? TC is growing rapidly. For sure it will (it must!) slow down and reach a more or less freeze state, but it is far at the moment. To support (both by core team and community) parallel versions is nearly impossible.
-
Added an exit, shortened some script, changed a few tests that weren't working correctly.
edit: moved exit to better location in script.
Now that tc has gone through many revisions, isn't it true that the latest extension revision might not work with previous versions of tc. I wonder if there should be a check of some kind that warns about this potential mismatch before the update takes place.
OK, I added a test that directs user to version 2.4 if they try to update a tce extension. I don't think extensions in the tce rep will get any future support though, so no sense updating with them.
Edit: I also included another test in case the update fails, such as with an md5.txt mismatch.
-
Added search option: "-s name" eg, "update -s perl"
tc@box:~$ update -s perl
microperl-5.8.9.tcz
perl5.tczl
perl_URI.tcz
perl_xml.tcz
Very fast search of the database
-
Version 2.6 resolves conflicts if coreutils are loaded. Also includes revisions for better file and dependency checks.
uses wget.tcz
[removed due to policy]
-
oops....had downloads commented out in -c option from testing.
edit: typo in -i option
-
what do u think about the short tce/z update scrip posted in
http://forum.tinycorelinux.net/index.php?topic=2056.0 (http://forum.tinycorelinux.net/index.php?topic=2056.0)
by SvOlli?
-
what do u think about the short tce/z update scrip posted in
http://forum.tinycorelinux.net/index.php?topic=2056.0 (http://forum.tinycorelinux.net/index.php?topic=2056.0)
by SvOlli?
Think you got wrong link, maybe http://forum.tinycorelinux.net/index.php?topic=2301.0 ?
Mine started with only a few lines, then evolved to fixing the menu, fixing the icons. To run without rebooting required removing links (or they don't copy). Other features, like first umounting tcz's added for safety. Changes needed to be handled for different editions. Recent versions, for example, won't update without first removing ext from tce. If you just want to get something into your tce dir and plan to reboot, you can just remove /usr/local/tce.installed and the ext from your tce directory and then reinstall. Note no safety precautions like umounting first, have been done prior to reinstall, but probably not a big deal with a PPR system loaded to RAM with a reboot.
-
For version 2.4.1
changes for:
permission changes: /tce.installed
possible .list files in tce dir
Uses: wget.tcz; recommended links browser for viewing list, dep, info files. Set paths at top of script.
Tutorial:
[removed due to policy]
edit: fixed -d option (neglected to remove test)
-
Added "if fi" to one of the APPS tests that occasionally breaks.
-
Script changes for possible .list files in tce dir
-
Allows reinstallation or download of tcz* or tce* extensions; duplicate menu issues get fixed on reboot. (note: reinstallation overwrites the loop and tce.menu, so it only looks like there are two copies)
example with xonclock:
tc@box:~$ sudo rm /usr/local/tce.installed/xonclock
Appsbrowser will now reinstall/download
i use for it emelfm or pcmanfm.
btw, why is tce-uninstall go away? ::)
-
Roberts:
may it's need to add update script to base system? this topic was viewed 3000times! 7 pages of hot talkings..... :D
-
Although I've used the script to update without issue a few thousand times, some feel it's safer to only update from base (in case an extension is still in use when reinstalling something). Worse case scenario is that a reboot will be necessary, although I've never even had to do that. Update removes symlinks and umounts tcz's & handles icons/menus before updating.
Scripts have the advantage of easy updating, although not everyone will know how to use them.
re: tcz-uninstall; same issues. It's in the archives, and probably a lot of us continue to use it.
-
I'm confused. I copied the script supplied above in the hopes of getting the latest and best, only to find that it is "Version 2.6" and a copy I had acquired on Oct 19 is "Version 2.7". The contents differ in many places. Which is the best choice for now?
Also, I notice that John's 17 Oct post says the script is made for version 4.2.1. Kudos for being ahead of the rest of tc's enthusiastic user base -- not to mention the developers -- by $(4.2.1-2.4.1) version units! ;) And thanks for a well made utility.
-
I edited a couple of times, and forgot to change the version #. It's the latest version, though. Thanks for pointing out the dyslexic typo. My mother always taught me to be forward looking. Hope the script is working for you, and thanks for trying it out.
note: the last edit is needed only if you have .list files in your tce_dir.
-
ver 2.8
..better handling of database, so md5's stay current.
fixed -d option (dependency checking) bug; (neglected to remove some test code)
Uses: wget.tcz; recommended links browser for viewing list, dep, info files. Set paths at top of script.
edit: Requires dialog.tcz as of tc_2.6 (dialog no longer in base)
Tutorial:
[removed due to policy]
-
Subtle bug: "update Mplayer-nodeps" fails with "No match found in tc directory". I think this happens because the second grep in the pipeline here
APP="$(busybox find ${A}.tc* | busybox grep -v .dep | busybox grep -v .txt)" &>/dev/null matches the substring "dep" in the extension's name, leading to the variable $APP getting assigned the null string. Some tuning of those grep commands appears to be required. (But hey, update worked on everything else! I'm still grateful!)
[This was update version 2.6, but I copied the offending line of script from the latest version, so I'm confident that the problem is still worth fixing.]
-
Thanks philip...hope this fixes it:
Version 2.8.1
Better grep commands
Uses: wget.tcz; recommended links browser for viewing list, dep, info files. Set paths at top of script.
Requires dialog.tcz as of tc_2.6 (dialog no longer in base)
Version 2.9:
added color for update candidates, prompt to reinstall
added "| less" to db and tce_dir viewer ( -vx , -v)
added test to remove error message when updating
Version 2.9.1
Added date to database viewer (update -vx)
Tutorial:
[removed due to policy]
-
updated to version 2.9
edit: devs2dev script for cleaning database files. Edit as we eliminate other 'plurals' from rep.
http://forum.tinycorelinux.net/index.php?topic=4047.0
-
Version 2.9.1 :
Added date to database viewer (-vx)
Old date probably means ext is discontinued
-
I wonder if you could add the updating of apps in/tce/optional? I keep a fair bit of stuff there for occasional use.
-
OK; think this will do it.
Version 3.0
New options:
-o APP " (eg," update gnumeric"} ; updates APP in tc/optional dir
-og" ; graphic option for updating tc/optional extensions
-remop ; graphic option to remove extensions from /optional dir
-co ; checks for update candidates in /optional dir
-id ; updates/builds database to dialog for new install (tce-load -w) to /optional dir
-idx ' lists database in dialog for new download to /optional dir
-vo ; views /optional directory
Version 3.1 New options: "update -sd <APP>" ; searchs within tce_dir dep files.
Uses: wget.tcz; recommended links browser for viewing list, dep, info files. Set paths at top of script.
Requires dialog.tcz as of tc_2.6 (dialog no longer in base)
Tutorial:
[removed due to policy]
-
Added new options for tce/optional directory: view, update, remove files, new downloads
-
Thanks! :)
-
Thanks! :)
You're welcome. Just updated with -idx option for fast downloads using the database. This should provide
nice tools for maintaining the /optional directory. Thanks for the suggestion.
-
Version 3.1
New search option for finding listings within tce_dir dep files. Also spruced up --help a bit.
example: "update -sd fontconfig"
[removed due to policy]apps/update-sd.png
edit: removed potential bug in -remop
-
version 3.2
updated view options; added "update -ve" for viewing installed extensions
Uses: wget.tcz; recommended links browser for viewing list, dep, info files. Set paths at top of script.
Requires dialog.tcz as of tc_2.6 (dialog no longer in base)
see update --help
Tutorial:
[removed due to policy]
-
Version 3.3
Added automatic backup of updated extensions in /tce/backup folder
New options:
--restore (or -res): Lists backups in Dialog for restoring to tce_dir
-rembak: Lists backup files for deletion.
Automatically restores extension to tce dir if an update fails.
updated grep, find searches.
added tests for /tmp/update-checks
Uses: wget.tcz; recommended: links browser for viewing list, dep, info files. Set paths at top of script.
Requires dialog.tcz as of tc_2.6 (dialog no longer in base)
see update --help
Tutorial:
[removed due to policy]
-
Version 3.4.1
Improved handling/building of database: now in tce dir.
add test to /tmp/choice
set Dialog menu to reflect /install/mount/download choice
add tests and echo results for successful deletions with -rem/-rembak/-remop
added automatic database folder install in tce dir, with option to build
new option:
--database
Removes old; downloads new md5 database
Uses links.tcz browser by default
Added "busybox" to ls for "-le" option
Uses: wget.tcz, dialog.tcz, and links.tcz
see update --help
Tutorial:
[removed due to policy]
-
Improved code for --database ( buggy test).
-
Hi jpeters,
your last update script (http://forum.tinycorelinux.net/index.php?action=dlattach;topic=1698.0;attach=450)* worked fine:
(http://i47.tinypic.com/2hzpfh1.png)
Running over your code and this thread I got the impression, the core updating logic might be the four steps only
(http://i46.tinypic.com/21kvuyr.png)
my one click update solution - posted last month (http://forum.tinycorelinux.net/index.php?topic=3672.msg20433#msg20433) - is based on.
(http://i45.tinypic.com/3mrm.png)
Naturally there are some additional details and a lot of optical stuff if you want to create a working solution - what can blow up these four steps to more than 1,000 lines of code.
But nevertheless the core are these four steps only, or did I overlook something?
JoXo009
---
* The script link may be visible and working only if you are logged in to this forum
-
Basically it..except update does a fresh check with the downloaded md5 instead of a diff against the old one.
for I in ${FILE}
do
sudo wget "ftp://$MIRROR/$DIR/${I}"
done
cd ${TCEDIR}
for I in ${FILE}
do
md5sum -c /tmp/md5/${I} >>/tmp/file-check
done
I'm not sure what you're asking. Update works without loading X , and includes a variety of checks for updating in addition to all search and appbrowser functions. It maintains a database for rapid offline checking, in addition to backups for updated extensions and includes various viewers and extension removal options. All the code is completely functional, and is devoid of GUI eye candy.
Note: To eliminate reboot, icons and menus have to be managed, in addition to umounting, deleting symlinks, etc.
-
Thanks, jpeters
Basically it
I just wanted to make sure, that I didn't overlook some important detail in the ready made virtual image I'm working on.
To eliminate reboot, icons and menus have to be managed, in addition to umounting, deleting symlinks, etc.
That's clear, but doesn't affect my version, as updating is combined with automatic reboot in my version for security reasons.
... the code is completely functional, and is devoid of GUI eye candy.
You are right, code functionality is important and an application isn't necessarily better because it is 'graphical'.
On the contrary, graphical interfaces often are just 'eye candy', funny pictures distracting the user from the real content.
On the other hand, script- and command line interfaces work for expert users only. And the more variations are build in the more expertise in needed.
So by adding a feature to a script interface you reduce the number of potential useres maybe by half. After adding ten features you may remain as single user as it makes no sense for others to invest two hours in learning features saving half an hour only.
To my opinion developping new features makes sense only if combined with an important reduction of learing time.
A possibility might be to offer a kind of manual as you do with your tutorial:
[removed due to policy]
Another possibility might be to create a human interface, something which uses all kind of media to communicate meaning and needed steps in an intuitive way understandable even for the newcomer.
-
I only post what I use myself. Regarding "safety", I can only say that after thousands of tests, it hasn't broken anything yet, and surprisingly I've never even needed to reboot; also no file corruptions. I'll have to conclude that it's completely safe on my setup, which is PPR, grub install with persistent tce directory on my HD. I wouldn't include "batch" anything, and you won't find "-q" (quiet mode) anywhere in the code, because I want to see everything that's happening for every download/update.
-
Version 3.5
added graphic/CLI choice to extension check: (e.g "update -f" or "update -f APP").
added graphic/CLI choice to extension check: (e.g "update -d" or "update -d APP").
added graphic/CLI choice to shared dependency check: (e.g "update -sd" or "update -sd APP").
added graphic/CLI choice to -inf: (e.g "update -inf" or "update -inf APP").
added graphic/CLI choice to -dp: (e.g "update -dp" or "update -dp APP").
added graphic/CLI choice to -ls: (e.g "update -ls" or "update -ls APP").
better grep code for -g option
added <return> commands after functions.
New: "gupdate": GUI frontend written in tcl-tk. Needs "update" in PATH or same directory.
requires: tcl_tk.tczl.
[removed due to policy]apps/gupdate.png
Update uses: wget.tcz, dialog.tcz, and links.tcz
Tutorial:
[removed due to policy]
-
Added binding to entry widget so it searches with <return> as well as button
-
For TC/MC_2.7 :no longer supports direct tcz2ram install.
Version 3.6
Removed tce-load -r option.
Update uses: wget.tcz, dialog.tcz, and links.tcz
"gupdate": GUI frontend written in tcl-tk. Needs "update" in PATH or same directory.
requires: tcl_tk.tczl.
[removed due to policy]apps/gupdate.png
Tutorial:
[removed due to policy]
-
Here's a neat function to search list files (with listbase). I'll post it in the next version:
[removed due to policy]apps/gupdate.png
-
Version 3.9
Listbase: folder of list files for entire rep. Useful for finding extensions that use particular files.
( presently about 17M....optional if you don't need searches)
added option --listbase: builds /db-list folder of list files in tce dir
added option -sl: searches through list files using listbase.
added rotdash when building database and listbase.
gupdate: added button for searches through list files
gupdate: added offline tce dir check (-cx) to menu
gupdate: GUI frontend written in tcl-tk. Needs "update" in PATH or same directory.
requires: tcl_tk.tczl.
[removed due to policy]apps/gupdate.png
Update uses: wget.tcz, dialog.tcz, diffutils.tcz and links.tcz
Tutorial:
[removed due to policy]
-
Added automatic checks for dep file changes with file (-f) and file dep (-d) checks.
Fixed bug in file checks.
-
Ver 3.9
added option -cd: checks dep files in tce dir for changes.
Note: uses diffutils.tcz for checks.
added depcheck to gupdate
-
Version 4.1
Removed bug in -cd (dep check); should work correctly now
Added option -vd: Views dependencies files in the tce dir; another tool to make sure all dep files are correct.
[removed due to policy]apps/view-deps.png
Update uses: wget.tcz, dialog.tcz, and links.tcz
"gupdate": GUI frontend written in tcl-tk. Needs "update" in PATH or same directory.
requires: tcl_tk.tcz.
[removed due to policy]apps/gupdate.png
Tutorial:
[removed due to policy]
-
Version 4.1
added: -vd now shows extensions listed in dep files not present in tce dir.
(note: a misplaced name will result in boot failure).
[removed due to policy]apps/view-deps.png
-
Howdy Folks,
Pardon me asking whether this is the tool to remove an on-demand pkg I had installed to /optional. If there's another way I haven't yet read about a pointer would do. Thanks.
-
Howdy Folks,
Pardon me asking whether this is the tool to remove an on-demand pkg I had installed to /optional. If there's another way I haven't yet read about a pointer would do. Thanks.
use "update -remop"
-
As I thought, thanks. The part I was unsure of was it's placement on the path.
Is /usr/local/bin/ a good home or one of the other path dirs preferable?
Nice script JPeters, thanks again.
-
As I thought, thanks. The part I was unsure of was it's placement on the path.
Is /usr/local/bin/ a good home or one of the other path dirs preferable?
Nice script JPeters, thanks again.
/usr/local/bin is always good (it's where I'd load it if I made an "update.tcz" extension). Personally, I place my scripts in /home/tc/.local/bin, which is included in PATH and gets backed up with my home directory.
In /home/tc/.profile:
if [ -d "$HOME/.local/bin" ] ; then
PATH=$HOME/.local/bin:$PATH
export PATH
fi
-
OK so you're simply appending a directory to the path. That little bit you got there could be done the same by inserting this somewhere no? Had to ask because my time to learn is limited. Thanks for your time and the example.
export PATH=$PATH:/home/tc/.local/bin
-
OK so you're simply appending a directory to the path. That little bit you got there could be done the same by inserting this somewhere no? Had to ask because my time to learn is limited. Thanks for your time and the example.
export PATH=$PATH:/home/tc/.local/bin
That will do it. I think it's already set up in .profile though, so it will save between boots. (I haven't checked in a while...at least it used to be).
-
update-build.sh: Builds update.tcz extension. Run in same dir with "update" script. (e.g. "sh update-build.sh").
requires squashfs-tools-4.0.tcz
#!/bin/sh
. /etc/init.d/tc-functions
DIR="."
mkdir -p /tmp/work/usr/local/bin
sudo cp ${DIR}/update /tmp/work/usr/local/bin
sudo chown -R tc:staff /tmp/work
sudo chmod 775 /tmp/work/usr/local/bin/update
cd /tmp/work
sudo mksquashfs ./ /home/tc/update.tcz
echo "${GREEN}update.tcz is in $HOME ${NORMAL}"
sudo rm -R /tmp/work
gupdate-build.sh: Builds gupdate.tcz extension. Run in same dir with "gupdate" script
#!/bin/sh
. /etc/init.d/tc-functions
DIR="."
mkdir -p /tmp/work/usr/local/bin
mkdir /tmp/work/usr/local/tce.menu
sudo cp ${DIR}/gupdate /tmp/work/usr/local/bin
cat <<EOF> "/tmp/work/usr/local/tce.menu/gupdate"
<JWM>
<Program label="gupdate">/usr/local/bin/gupdate</Program>
<JWM>
EOF
sudo chown -R tc:staff /tmp/work
sudo chown -R root:staff /tmp/work/usr/local/tce.*
sudo chmod 775 /tmp/work/usr/local/bin/gupdate
sudo chmod 775 /tmp/work/usr/local/tce.*
sudo chmod 644 /tmp/work/usr/local/tce.menu/gupdate
cd /tmp/work
sudo mksquashfs ./ /home/tc/gupdate.tcz
echo "${GREEN}gupdate.tcz is in $HOME ${NORMAL}"
sudo rm -R /tmp/work
-
Version 4.2.1
Automatically loads its own deps if not present. (links,wget,dialog,diffutils).
For tcl_tk (dep for gupdate), uncomment it out in load() section (lines 49,56)
Tutorial:
[removed due to policy]
-
Version 4.2.1
bug fix in -rem & -remop: discriminate underscored file names
-
Version 4.2.1
Automatically loads its own deps if not present. (links,wget,dialog,diffutils).
For tcl_tk (dep for gupdate), uncomment it out in load() section (lines 49,56)
Tutorial:
[removed due to policy]
What new sick policy forbids a link to a tutorial?