Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: bigpcman on May 21, 2009, 09:22:32 AM
-
Does tcz-uninstall.tce have the -f option that allows a command line uninstall of a single tcz app?
-
Yes, "tce-uninstall --force pango" would uninstall firefox without any regard to files above /usr/local, whether the extension is in use, or whether there are apps installed that depend on pango. I will add that to the info file.
-
Yes, "tce-uninstall --force pango" would uninstall firefox without any regard to files above /usr/local, whether the extension is in use, or whether there are apps installed that depend on pango. I will add that to the info file.
I presume you mean "tcz-uninstall".
-
Yes, "tce-uninstall --force pango" would uninstall firefox without any regard to files above /usr/local, whether the extension is in use, or whether there are apps installed that depend on pango. I will add that to the info file.
I just tried "tcz-uninstall --force tightvnc" as well as "tcz-uninstall --force tightvnc.tcz" and get the menu in both cases.
The menu works great. However I get the following message:
Xlib: extension "Generic Event Extension" missing on display ":0.0".
--------------------------------------------------------------------------------------------------
edit: I just tried "tcz-uninstall --force tightvnc &" in a script and got the following results:
rm: cannot remove '/user.tar.gz': No such file or directory
bash has been uninstalled.
Xlib: extension "Generic Event Extension" missing on display ":0.0".
In this case tightvnc had already been removed so it looks like the uninstall automatically picked up the first tcz on the menu (bash) and uninstalled it. Yikes - that's not good!
---------------------------------------------------------------------------------------------------
edit 2: I just tried "tcz-uninstall &" in a script and got the same above results.
-
My bad, I thought we were talking about tce-uninstall. I misread.
I will look at tcz-uninstall when I get home. I cannot remember if there is a --force option to it as it is not needed, tcz-uninstall does not need a force option as it's only check is if the extension's files are in use. You would not want to uninstall an extension in use anyway, but I will see if I can't fix the scenario you described.
-
My bad, I thought we were talking about tce-uninstall. I misread.
I will look at tcz-uninstall when I get home. I cannot remember if there is a --force option to it as it is not needed, tcz-uninstall does not need a force option as it's only check is if the extension's files are in use. You would not want to uninstall an extension in use anyway, but I will see if I can't fix the scenario you described.
Actually all I am looking for is a way to uninstall a named tcz app from within a script.
-
"tcz-uninstall firefox" should but I will check more tonight as I haven't looked at tcz-uninstall in a while.
-
"tcz-uninstall firefox" should but I will check more tonight as I haven't looked at tcz-uninstall in a while.
Hello Jason,
Did you get a chance to look at the tcz-uninstall script. I double checked and got the same results. For instance tcz-uninstall emelfm2 brings up the menu and does not remove the program. Also, just to confirm how the script works, it looks like all dependent tczs have to uninstalled one by one.
-
No, I didn't get a chance. Dealing with extension submissions is what I place as first priority, and on occasion takes it all my available time. But I will check into it when I can, hopefully tonight.
As for dealing with dependencies, I personally prefer simplicity but I may work dep handling in one day.
-
Jason there appears to be three issues I have run into with the tcz-uninstall script.
1. If a tcz name is given on the command line the menu still comes up and the tcz is not uninstalled.
2. If a tcz name is given on the command line and its not in the menu weird things happen.
3. The flwm menu is not updated after a tcz is uninstalled.
-
Now that jwm is not the only window manager there will have to be some adjustment to tcz-uninstall and tce-uninstall. As well as the bugs you mentioned, which those should be an easy fix. Thanks for the feedback, a test case for which wm is running should enable proper menu updating.
-
I fixed the command line issues you mentioned, but the window manager menu handling is still in development for 2.x so there is no need to spend much time on it now when details may change. I will work up a routine that will accommodate the various window managers after release. Also, a --force option is not going to work as the tcz will not be unmounted by umount if it is still in use. The extension must not be in use for tcz-uninstall to work, dictated by the umount command. So tcz-uninstall is of little value in scripts, just as a user utility.
Thanks for reporting on these issues.
-
I fixed the command line issues you mentioned, but the window manager menu handling is still in development for 2.x so there is no need to spend much time on it now when details may change.
The extension must not be in use for tcz-uninstall to work, dictated by the umount command. So tcz-uninstall is of little value in scripts, just as a user utility.
How about if the script kills the app process, does a umount on the tcz and then an uninstall of the tcz?
-
That is definitely doable, though potentially causing unexpected results of apps being killed and lost data. Though the "--force" name does imply just that. The tce-uninstall's version of --force does not kill any apps, just deletes their files so they could not be relaunched. Killing apps may be a bit much, let me sleep on it.
-
Jason I just tried the kill, umount and uninstall for tightvnc. Do I have the umount right?
tc@box:/$ sudo umount /tmp/tcloop/tightvnc
tc@box:/$ tcz-uninstall tightvnc
tightvnc is still in use and will not be uninstalled.
-
The umount is right, but manually umounting a tcz directory in /tmp/tcloop is well outside the normal use of tcz's. I will put a check in there that will use different test cases that will take manual umounting into consideration. I also see a potential bug that can be fixed in the dialog creation.
-
The /tmp/tcloop direcory being mounted is the crucial info for whether an extension is installed as a tcz. /usr/local/tce.installed does not provide that info. Umounting the /tmp/tcloop/appname directory is essentially breaking the tcz extension install. The files (symlinks) that are removed from the system are determined by reading that directory. And to place further checks in the script that would act in the absence of the /tmp/tcloop/appname directory mount would jeopardize installed tce extensions.
However, using a lazy umount does the same trick as the --force uninstall of the tce-uninstall. I can "umount -l /tmp/tcloop/emelfm2" and still use the emelfm2 binary running in ram, it does not kill the process just makes the app unable to relaunch. That I can live with.
I will add a --force option.
-
Jason I just tried the most recently posted tcz-uninstall.tce and the command line worked. I did kill the app process before the uninstall. So that is good news - thanks for the effort.
There is a message that pops out:
Xlib: extension "Generic Event Extension" missing on display ":0.0".
Any idea what causes this?
Edit: I just noticed that after the uninstall completes the tcz-uninstall menu still shows the tcz that was just uninstalled but if it is selected it reports that the tcz is not found.
-
Something to do with the location of rgb.txt maybe?
-
The Xlib error shows with a lot of apps when issued from the terminal, wbar I believe is the one that shows it here when being restarted.
I am in the middle of some more improvements since I uploaded the last update. The --force option will be included, some more bugfixes including the tcz-uninstall menu issue just mentioned.
I am still debating on whether to add dependency handling. If it does not slow things down too much, then I will add it in. Tce-uninstall can be miserably slow due to the manner in which it checks for files in use and fetching list files, but tcz-uninstall can obtain the same info on extensions in a small fraction of the time since it has to retrieve nothing and only has to check if mountpoints are being used, not individual files. So no slowdown should occur by adding dep handling, I will test it and see.
-
My strong personal preference would be to include the dependencies in the uninstall since I always uninstall tcz apps when I'm done using them and it's a pain to have to hunt done all the dependencies in the menu.
I assume if there is more than one app using the dep than you would not remove it.
-
Just uploaded a fixed tcz-uninstall, and from what I can see the issues have been corrected. The --force option is also available.
I will add dependency handling in time. I just don't have the time right now it will require, but maybe in the coming weeks.
EDIT: Upon remembering, to deal with dependent apps requires downloading the .dep files for each extension installed that has one. That is part of what makes tce-uninstall so slow at least with first usage, but the .list files have to be downloaded for tce-uninstall for it to function so fetching the dep files does not detract as much from tce-uninstall. Tce-uninstall is made for PPI usage anyway, so that downloading of list and dep files only happens once. But it would ruin the tcz-uninstall experience as the dep files would have to be downloaded again after every boot. I will leave dep handling out of it to preserve the simple and fast usage of this utility.
-
Jason thank you for all the work on tcz-uninstall. I'm testing it out now.
So far everything looks great. There is just one small problem.
I installed samba which installs cups as a dependency to test out the uninstall tool. After uninstalling both samba and cups the cups app still shows up in the desktop menu. A screen refresh does not help. It's gone from wbar so that part worked. However, the following cups files are still present. As near as I can tell there is no cups process running. Also a few of samba files are left behind.
./etc/cups
./etc/cups/cupsd.conf
./etc/cups/cupsd.conf.default
./etc/init.d/cups
./usr/local/share/doc/cups
./usr/local/share/cups
./usr/local/include/cups
./usr/local/tce.flwm/cups
./usr/local/lib/cups
./etc/samba/smb.conf
./etc/samba/private/smbpasswd
./etc/samba/private/secrets.tdb
./var/run/nmbd.pid
-
I will get to the flwm menu entries in time, it will require some awk scripting basically reversing the flwm_makemenu function.
The files you mention are the user.tar.gz files that are left over after uninstall. That is by design as those are real files and depending on the extension maker they may be critical system files that get overwritten. Therefore by default they are not deleted. But I have added the deletion of those files to the --force option since --force always implies risk. I also added a --purge command line function that allows the removal the the tcz and relaged files in the tcz directory. That way one can uninstall a tcz and then use the appbrowser to install a newer version without issue. There is also a dialog when the menu is used that asks if one wants the files in the tce directory deleted. A --help option is also added. Basically:
tcz-uninstall brings up menu
tcz-uninstall --help echoes help contents
tcz-uninstall appname uninstalls appname.tcz
tcz-uninstall appname --force force uninstalls appname.tcz
tcz-uninstall appname --purge uninstalls appname.tcz and it's files in the tce directory+
tcz-uninstall appname --force --purge Combines --force and --purge, their order is not important.
-
This brings up some interesting issues regarding automatic functions in general. The beauty of PPR is that I can just delete the file from my tcz folder, and problem solved. I can look at the dep list to choose other files I want to delete (it always helps to understand what they are) Automatic functions like not being allowed to download an app because it's already installed are a nuisance for the reason you stated, although the primary reason why I would need yet another automatic function such as tcz-unstall......so that I will be "allowed" to download an update. Of course, I'll have to wait for tce-uninstall to extend the privilege to tce apps.
-
Jason I tried the tcz-uninstall again on samba and cups using the --force and --purge options. The results are exactly the same. All the same files remain present. Also I should note that samba must be killed (smbd and nmbd) before the uninstall tool is used or it won't work.
On the cups uninstall there are error messages:
sed: /usr/local/tce.menu/menu: no such file or directory
rm: can not remove '/user.tar.gz': no such file or directory
I'm a little confused about the cups menu entry removal problems since I don't have a lot of experience messing around with flwm. But all I did was remove cups from /home/tc/.wmx/Applications and restarted flwm and cups was gone. So I don't understand this:
I will get to the flwm menu entries in time, it will require some awk scripting basically reversing the flwm_makemenu function.
edit: By the way the --force and --purge options are excellent ideas!
-
The flwm menu files in .wmx/Applications are not necessarily the same as the extension name, it can be any name that the extension maker wants in the menu. It is derived from entries in /usr/local/tce.menu/extensionname, it is not just the simple scripted removal of a file based on extension name as that file can have any name. It will take scripting to check for a couple of variables in the /usr/local/tce.menu/extensionname, Menu first then Program.
I tested cups with --force and the files were deleted, the directories remained. The directories remain as you do not want to remove /usr, /etc, and the like, which is what will happen if the extension maker includes base directories in the user.tar.gz. I will test this more.
"sed: /usr/local/tce.menu/menu: no such file or directory" means you don't have a /usr/local/tce.menu/menu file, that file is supposed to be there, at least last I checked. If not, a test for the file can occur.
"rm: can not remove '/user.tar.gz': no such file or directory" happens because the user.tar.gz is not symlinked into the filesystem. That is cosmetic and can be fixed.
-
I see your point on the flwm menu app removal. That will take some work.
Ok so after the uninstall of cups all this stuff will remain by design. Is that correct?
tc@box:~$ sudo killall smbd
tc@box:~$ sudo killall nmbd
tc@box:~$ tcz-uninstall cups --force
sed: /usr/local/tce.menu/menu: No such file or directory
rm: cannot remove '/user.tar.gz': No such file or directory
cups has been uninstalled.
tc@box:~$ Xlib: extension "Generic Event Extension" missing on display ":0.0".
tc@box:~$ cd /
tc@box:/$ sudo find . -name "*cups*"
./etc/cups
./etc/cups/cupsd.conf
./etc/cups/cupsd.conf.default
./etc/init.d/cups
./usr/local/share/doc/cups (help/ images/)
./usr/local/share/cups (banners/ charmaps/ charsets/ data/ drivers/ fonts/ model/ templates/)
./usr/local/include/cups
./usr/local/tce.flwm/cups
./usr/local/lib/cups (backend/ cgi-bin/ daemon/ filter/ monitor/ notifier/)
tc@box:/$
-
Directories created by the installation of the tcz or the user.tar.tz are supposed to remain, removing empty directories created by the install of the tcz could be done. I will consider it as it does make sense.
I will check into why the files are left behind when using the --force option. I will not have much time with TC this week so it may take a while.
-
Directories created by the installation of the tcz or the user.tar.tz are supposed to remain, removing empty directories created by the install of the tcz could be done. I will consider it as it does make sense.
I will check into why the files are left behind when using the --force option. I will not have much time with TC this week so it may take a while.
Jason you are doing a great job! Thanks again for all your effort. Tcz-uninstall has been substantially improved. I look forward to your future improvements as they become available.
-
Adding findutils as a dependency and a one liner like this would get rid of the empty directories ( I am on windows now but here is off the top of my head):
find /tmp/tcloop/"$APP" -type d -empty -print0 | \
sed "s:\/tmp\/tcloop\/"$APP"::"| xargs -0 rm -r
Especially with the window manager changes this script needed some attention, hopefully the next update will be pretty much polish it off. Thanks for the ideas and feedback.
-
Without requiring findutils, one could just:
find /tmp/tcloop/"$APP" -type d | sed "s@\/tmp\/tcloop\/${APP}@@" | xargs rmdir
I haven't tested this code, but rmdir doesn't remove a directory if there's even a single file.
-
Thanks curaga, I added that and it saved a few lines of test cases and such and the need for findutils.
Sudo was missing in a couple of places, hence files left behind. Hopefully fixed the remaining bugs, uploaded the result. Hopefully all that is left now is supporting the different window managers.
-
Without requiring findutils, one could just:
find /tmp/tcloop/"$APP" -type d | sed "s@\/tmp\/tcloop\/${APP}@@" | xargs rmdir
I haven't tested this code, but rmdir doesn't remove a directory if there's even a single file.
Doesn't this yield "/" ? (I don't understand the sed 's@/dir/dir@@' part )
-
/ has files in it, thus it doesn't get removed
-
Without requiring findutils, one could just:
find /tmp/tcloop/"$APP" -type d | sed "s@\/tmp\/tcloop\/${APP}@@" | xargs rmdir
I haven't tested this code, but rmdir doesn't remove a directory if there's even a single file.
Can this command be made to work recursively? That is if an empty folder is deleted and the deletion causes the parent folder to be empty and so on can all the empty folders in sequence be deleted?
-
/ has files in it, thus it doesn't get removed
weird....I typed the exact same command into another terminal, and it worked. The find was literally
producing "/" instead of /dir/dir
-
Can this command be made to work recursively?
Not easily, so rerunning it a couple times is an easy solution for recursion
edit:
weird .... it worked.
:D
-
Can this command be made to work recursively?
Not easily, so rerunning it a couple times is an easy solution for recursion
edit:
weird .... it worked.
:D
You mean it works recursively as is? If so can you explain how?
-
No, it doesn't work recursively, I just had to point out jpeters' well chosen words ;)
-
An updated version has been uploaded that removes all the empty dirs.
EDIT:
Note: the directories, if any, that are created by the user.tar.gz remain in the system after a --force uninstall. That is harmless and a small detail I think we can live with.