How to install a Pet file from the command line?

Using applications, configuring, problems
Message
Author
User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#21 Post by greengeek »

MochiMoppel wrote:BTW. Fiddled a bit more: This should also work. Looks a bit cleaner and removes pet.specs and any puninstall.sh
Thanks - just incorporated that into my test script and that seems to give me what I am looking for. (I really am only concerned about getting the pet installed and not worried about uninstalling tidily as this method will be used without savefile - it is all running in ram and gets dumped when i shut down)

I did note that the terminal showed a "Child returned status 2" error. Is this perhaps similar to the "wrapper exited with an error" message I see when untarring a pet by adding a .tgz suffix during manual unzipping of a pet?

Code: Select all

#!/bin/bash
#2015Jun9 greengeek script to automatically graft a specific pet into the
#filesystem during boot or shortly thereafter (eg running from /root/Startup)
#Syntax from MochiMoppel (thanks!)
#http://murga-linux.com/puppy/viewtopic.php?p=849832#849832
#Added fixmenus and jwm reload
cd /
tar --strip-components=2 -xf /opt/b3user/FoxitPDF_b3gg-0.1.pet
/pinstall.sh
rm pinstall.sh puninstall.sh pet.specs
fixmenus
sleep 5
jwm -reload

Code: Select all

# ./PetGraft

gzip: stdin: decompression OK, trailing garbage ignored
tar: Child returned status 2
tar: Error is not recoverable: exiting now
./PetGraft: line 4: /pinstall.sh: No such file or directory
rm: cannot remove ‘pinstall.sh’: No such file or directory
rm: cannot remove ‘puninstall.sh’: No such file or directory
Generating /root/.icewm/menu...
Generating /root/.jwmrc...
# 
Next step will be to have the script run through a list of desired pets or a specific directory of pets in it's entirety. I will look at the 4M method and see if it points me in the right direction.
.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#22 Post by MochiMoppel »

greengeek wrote:I did note that the terminal showed a "Child returned status 2" error.
If it bothers you then you should run pet2tgz to clean the garbage.

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#23 Post by slavvo67 »

There's a thread on the board for this, already. Someone amended Barry's pet installer for me without the pop-ups so I could install a whole directory of pets and still remove them with PPM. I think it was Mikeb's work.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#24 Post by greengeek »

slavvo67 wrote: Someone amended Barry's pet installer for me without the pop-ups so I could install a whole directory of pets and still remove them with PPM. I think it was Mikeb's work.
Thanks Slavvo - I just did another search and came up with this thread:
http://www.murga-linux.com/puppy/viewtopic.php?t=93287
I don't see mikeb in there- could it have been another thread or is that the one?
(also links to Dejans offering here)

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#25 Post by seaside »

greengeek,

You may want to consider another approach. Create a "validate and change" script to check and change pet files before placing them in a "quick load directory".

This would consist of basically the petget validation code and instead of installing, it would just change the .desktop file to conform to puppy standards.

Since a pet file can be treated as a tar file, a .desktop file can be extracted, changed and put back into the .pet file with any corrections needed. Now, all pets that were run throught the "validate and change" script will not have non-standard puppy .desktop files, which probably takes the most time with "find" calls in petget.

Cheers,
s

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#26 Post by greengeek »

Thanks seaside. Based on this thread and also these other two:
http://www.murga-linux.com/puppy/viewtopic.php?t=93043
http://www.murga-linux.com/puppy/viewtopic.php?t=93287

I am realising more about what it takes to install a pet and I see now that I may need more than one approach for my automatic pet installing needs. I would summarise them like this:

1) When a pet is clicked it invokes petget and install.pkg etc and the pet is checked for consistency with Puppy standards, reshaped to some degree then installed. (I had no idea previously that so much was being done behind the scenes). Petget is verbose and does not lend itself to an unattended commandline method. (It also handles passing uninstall info to PPM)

2) The slavvo/rufwoof script allows the user to invoke a silent form of petget that does not involve ongoing user interaction (and allows uninstall info to be passed to PPM).

3) There are various ways to unpack a pet directly into the filesystem for speed, but these do not pass uninstall information to the PPM. This is fine for most of my current needs.

4) As you have suggested it may be possible to use petget to prepare the pets before they are passed into a storage directory from where they can be invoked by commandline. I would probably use this as a preparatory step rather than an on-the-fly method in my particular case. I presume this method will not produce uninstall functionality for PPM.

Summary:

Any method that does not use petget runs the risk of grafting non-Puppy-standard desktop files into the filesystem and causing various problems such as damaged menu items as well as potentially other programme functions. Therefore pets that are intended for installation via a commandline route may need to be "Puppy Standardised" before being used. Under some circumstances Pinstall scripts may also need to be scrutinised to ensure that they are compatible with a no-X environment (or removed completely and replaced by further changes to the pet).
ie: in selecting pets that will work with commandline installation it is not good enough to just click on a pet to see if it works with your puppy - it is necessary to see if it still works when grafted into the filesystem "as is" without the mods that the petget installer does behind the scenes.

At the moment I will concentrate on the commandline offerings that have been suggested, and focus on working out what is wrong with the pets that give trouble via this method. This will give me a better understanding of what Puppy expects to see in a pet.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#27 Post by MochiMoppel »

greengeek wrote:1) When a pet is clicked it invokes petget and install.pkg etc and the pet is checked for consistency with Puppy standards
What petget version are you talking about? There are distict differences between the "classic" petpet and the petget that comes with PPM2. In general the PPM2 petget will be more difficult to silence.
It also handles passing uninstall info to PPM
It creates uninstall information which it can handle itself, no PPM needed. To be precise: The information is processed by removepreview.sh. Both petget (for a non-GUI uninstallation) and PPM (if you prefer a GUI) use removepreview.sh to do the actual uninstallation.
3) There are various ways to unpack a pet directly into the filesystem for speed, but these do not pass uninstall information to the PPM.
Your 'various ways" essentially do the same what petget does. You can strip petget down to this one core tar command, extracting the pet to the file system. But if you need uninstall information, you will have to add 2 more command lines, if you want menus, then you will need some more lines ...and ...and...
Therefore pets that are intended for installation via a commandline route may need to be "Puppy Standardised" before being used.
No, not the pets have to be adapted, your script has. All pets can be installed from command line. Or maybe I'm confused by your usage of 'command line'.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#28 Post by greengeek »

Code: Select all

1) When a pet is clicked it invokes petget and install.pkg etc and the pet is checked for consistency with Puppy standards
What petget version are you talking about? There are distict differences between the "classic" petpet and the petget that comes with PPM2.
My puppy deivative is based on Slacko 5.6 as it seems to be very stable on my hardware and therefore I am using the original PPM. So far I have no experience with PPM2.
To be precise: The information is processed by removepreview.sh. Both petget (for a non-GUI uninstallation) and PPM (if you prefer a GUI) use removepreview.sh to do the actual uninstallation.
What I meant was that using the standard pet installation method that calls "petget" and it's associated scripts results in a pet installation that can be uninstalled easily by using the PPM gui. (In contrast to some of the other more manual methods of intalling pets that graft the pet contents into the filesystem but don't correct "errors" in the pet construction (desktop files etc) and don't create the "uninstall information" that allows the user to uninstall that pet via the PPM gui)

Code: Select all

There are various ways to unpack a pet directly into the filesystem for speed, but these do not pass uninstall information to the PPM.
Your 'various ways" essentially do the same what petget does.
I disagree. (which is probably stupid as I know you have so much experience with this stuff and i am a newcomer :-) ) But what I now see is that petget is capable of changing the pet structure (or contents if you prefer) whereas the commandline methods I have been trialling do not do the same thing as petget. Obviously they could if written differently, but in the form I have been trialling them the commandline methods do much less than petget seems to do (at least with some of my pets).
You can strip petget down to this one core tar command, extracting the pet to the file system.
Except that it is possible to be installing a pet that is not formed according to the "Puppy standard". What I am seeing is that some of my pets install correctly via commandline and some do not - even though they all install correctly when i click them (which I believe invokes petget)

Code: Select all

Therefore pets that are intended for installation via a commandline route may need to be "Puppy Standardised" before being used.
No, not the pets have to be adapted, your script has. All pets can be installed from command line.
I have some pets that install correctly using the commandline syntax but also a number of pets that do not install correctly (using commandline syntax either from yourself or seaside or others from a couple of other threads) and this seems to be due to problems with the icon path spec missing from the .desktop file or the "categories" spec containing multiple entries (which seems unacceptable to puppy unless petget is used to clean up the desktop file)
Or maybe I'm confused by your usage of 'command line'.
That wouldn't be surprising. My usage of the commandline often surprises me too. It is one reason I now use Puppy from .sfs only rather than using a savefile. The commandline is dangerous :-)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#29 Post by MochiMoppel »

You seem to have lost focus.
You want to extract a specified number of packages at startup. Silently - without user intervention. If this is still your objective then forget petget and concentrate on the few commands needed to get this done.
To solve your icon/desktop/menu problems: Why do you care at all? Yes, .desktop files can be tricky and may not produce the menu entries you expect, but if you are dealing with a limited number of packages why not prepare a menu for all of them beforehand? As you have seen the cleaning procedures in petget are elaborate and creating menus with fixmenus is slow and clumsy.

Here is what I would do:
Extract the pets, get rid of pet.specs and .desktop files and repack into .txz packages. Your slacko will like it. This also eliminates the md5sum and the odd installation folder required by .pets (which, by the way, can be 1 or 2 levels deep, requiring 2 different strip settings in tar - so much about "standards" in pets).

Your slim and fast .txz packages can then be installed at startup or - which I would prefer - on demand. You could create a run script for application myapp which would check if myapp is already installed, if not then extract myapp.txz, then run myapp. This will not slow you down, but would avoid installing packages 'just in case' , even if you don't need them during your session.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#30 Post by greengeek »

MochiMoppel wrote:Here is what I would do:
Extract the pets, get rid of pet.specs and .desktop files and repack into .txz packages. Your slacko will like it. This also eliminates the md5sum and the odd installation folder required by .pets ...
Thanks - are you saying that a .txz package when installed will still allow the programme to appear in the menu without a desktop file? Whichever method i use it will be important that users unfamiliar with the commandline still be able to access the packages that get installed during boot.

(To offer more info - The user will boot my derivative in its "generic" state the first time, then choose certain personalisations, then the system automatically burns them a new personalised CD. As part of that personalisation the user will have chosen additional programmes to be made available in the personalised Puppy and the "install pets" script in the Startup directory will do this for them each boot. I will coach them over the phone regarding which pets to move into the "pets2install" directory during personalisation and the system will do the rest for them without them having the faintest idea how to remaster. But it is critical that the added programmes be available in the menus).

So yes - I could possibly use some other form of package, as long as they can drag 'n' drop it to the required location. The smaller the package the better as it is carried inside my iso as a "payload" in its compressed form. The other advantage of using the .pet format is that it allows the user to install it while their system is running - they are not forced to do a reboot or burn a new CD if they prefer a manual "on-demand" install. They can just click the .pet and accept the prompts.

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#31 Post by plinej »

Old thread but I'll post my script that can install local pet and deb files without X. You will also be able to use PPM to uninstall later if you wish.

to install a package:
petget2 fox-1.2.pet

to list all user installed packages:
petget2

to list all user installed packages that start with fox:
petget2 fox

to list all files installed in the package(s) that start with fox:
petget2 fox list

to uninstall all packages that start with fox:
petget2 fox remove

Code: Select all

#!/bin/bash

jwm=`ps aux | grep jwm | grep -v grep`

installed=`ls /var/packages/*.files | uniq -u | cut -f 4 -d '/' | sed 's/\.files//'`

#list all installed packages
if ! [ "$1" ]; then
   echo "$installed"
   exit
fi

if [ -f "$1" ]; then
   install=yes
   noext="`echo ${1%.*}`"
   ext=${1##*.}
   extlow=`echo "$ext" | tr -s [A-Z] [a-z]`
   mv "$1" "$noext"."$extlow" 2>/dev/null
   file="$noext"."$extlow"
   noext2=`basename "$noext"`
fi

if [ "`echo $file | grep '.deb'`" != "" ]; then
   echo installing "$file"
   mkdir "$noext" 2>/dev/null
   if [ `ar t "$file" | grep data.tar` = data.tar.xz ]; then
      ar p "$file" data.tar.xz | tar xJ -C "$noext"
      rm -f data.tar.xz 2>/dev/null
   elif [ `ar t "$file" | grep data.tar` = data.tar.gz ]; then
      ar p "$file" data.tar.gz | tar zx -C "$noext"
      rm -f data.tar.gz 2>/dev/null
   fi
   rm -f control.tar.gz 2>/dev/null
   rm -f debian-binary 2>/dev/null
fi

if [ "`echo $file | grep '.pet'`" != "" ]; then
   echo installing "$file"
   cp "$file" "$file".bak
   pet2tgz "$file"
   if [ -f "$noext".tar.xz ]; then
      tar -xf "$noext".tar.xz
      rm -f "$noext".tar.xz 2>/dev/null
   elif [ -f "$noext".tar.gz ]; then
      tar -zxvf "$noext".tar.gz
      rm -f "$noext".tar.gz 2>/dev/null
   fi
   mv "$file".bak "$file"
fi

if [ "$install" = yes ]; then
   if [ -d "$noext2" ]; then
	cd "$noext2"
	if [ -f pinstall.sh ]; then
		./pinstall.sh
		rm pinstall.sh
	fi
    if [ -f pet.specs ]; then
		info=`cat pet.specs`
        echo -e "$info" >> /var/packages/user-installed-packages
		rm pet.specs
	else
		echo -e "$noext2" >> /var/packages/user-installed-packages
	fi
	#cp -af * / 
	rsync -a * /
	find -L ./ -type f | sed 's/.//' | sort -u > /var/packages/"$noext2".files
	desktop=`cat /var/packages/"$noext2".files | grep '.desktop'`
	cd ../
	rm -rf "$noext2"
	if [ "$desktop" != "" ]; then
		fixmenus
		if [ "$jwm" != "" ]; then
			jwm -restart
		fi
	fi
	else
		echo no "$noext2" directory found
	fi
   exit
fi

#find installed packages with given name
packages=`echo "$installed" | grep ^"$1"`
if [ "$packages" != "" ]; then
	num=`echo "$packages" | wc -l`
	echo
	echo $num package\(s\) found
	echo
	echo "$packages"
	echo
	if [ "$2" = remove ]; then
		echo "$packages" | while read pkg; do
		echo removing "$pkg" now
		desktop=`cat /var/packages/"$pkg".files | grep '.desktop'`
		cat /var/packages/"$pkg".files | while read file; do
			#if [ -f "$file" ]; then #doesn't always work with symlinks
			if ! [ -d "$file" ]; then
				echo removing "$file"
				rm "$file" 2>/dev/null
			fi
		done
		cat /var/packages/"$pkg".files | sort -r | while read file; do
			if ! [ -d "$file" ]; then
				dir=`dirname "$file"`
				if [ -d "$dir" ]; then
					echo searching for empty directories to remove in "$dir"
					find "$dir" -type d -empty -delete 2>/dev/null
				fi
			else
				echo searching for empty directories to remove in "$file"
				find "$file" -type d -empty -delete 2>/dev/null
			fi
		done
		rm /var/packages/"$pkg".files
		cat /var/packages/user-installed-packages | grep -v ^"$pkg" > /var/packages/user-installed-packages.new
		mv /var/packages/user-installed-packages.new /var/packages/user-installed-packages
		done
		if [ "$desktop" != "" ]; then
			fixmenus
			if [ "$jwm" != "" ]; then
				jwm -restart
			fi
		fi
	fi
	if [ "$2" = list ]; then
		echo "$packages" | while read pkg; do
			cat /var/packages/"$pkg".files | sort -u
		done
	fi
fi

Last edited by plinej on Fri 25 Oct 2019, 14:03, edited 64 times in total.
You can also download many of my packages at:
[url]https://archive.org/download/python3-git-2019-10-10-x86_64[/url]

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#32 Post by plinej »

delete
Last edited by plinej on Thu 03 Oct 2019, 00:54, edited 2 times in total.
You can also download many of my packages at:
[url]https://archive.org/download/python3-git-2019-10-10-x86_64[/url]

plinej
Posts: 1742
Joined: Mon 14 Aug 2006, 02:21

#33 Post by plinej »

delete
You can also download many of my packages at:
[url]https://archive.org/download/python3-git-2019-10-10-x86_64[/url]

Post Reply