Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 23 Jan 2019, 18:33
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Need a .pet automation script to:
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [3 Posts]  
Author Message

Joined: 22 Mar 2016
Posts: 64

PostPosted: Mon 09 Apr 2018, 17:00    Post subject:  Need a .pet automation script to:
Subject description: (1) Install (2) load (3) use (4) close and automatically uninstall

Dpup Stretch 7.5 CE (RC-2) from radky is my only workhorse.

Earlier this week fredx181 kindly provided a youtube pet @
and it works very well.

I would like to able to automate the installation and uninstallation of this pet (or any pet) upon its closure. I can see how to do this in a longish and inelegant script with substantial help from xdotool with lots of mousemoves and clicks; but it seems certain something brief, elegant and probably more comprehensive (e.g. perhaps for use with many Pups and also auto handling other packages) already exists.

Any help would be greatly appreciated.

EDIT (prior to next post - so time unchanged):

My semi-automatic solution (ignoring xdotool mousemoves and clicks):

petget /mnt/home/stretch/pet/youtube*
petget -youtube-viewer_3.3.1.pet


Great news (thanks to MochiMoppel and his coding skills) now:

Firstly, (exactly as requested),

I can “instantaneously” install and load the youtube (or any) pet;
+ when ready, close and uninstall even faster with a second click.

Secondly, (and alternatively),

In 4 seconds I can install 4 .pets and 3 .debs to my jwm menu,
In another 3 seconds I can uninstall them, also with a single click.

To add another ‘n’ pets (say, 50 if sufficient Puppy space) I would
only have to drag and drop them into my existing pet directory.

Last edited by mfb on Thu 21 Jun 2018, 08:06; edited 1 time in total
Back to top
View user's profile Send private message 

Joined: 26 Jan 2011
Posts: 1747
Location: Japan

PostPosted: Tue 10 Apr 2018, 23:59    Post subject: Re: Pet automation script to:
Subject description: (1) Install (2) load (3) use (4) close and automatically uninstall

Sounds like you want to do what I described in "Use case 2" in this old thread.
Obviously nobody sees a need for a solution - except me and maybe you.

My fully automatic solution would read
petget -q /mnt/home/stretch/pet/youtube*
petget -uq /mnt/home/stretch/pet/youtube*
Send me a PM if you are interested. I can't guarantee that it still works Wink
Back to top
View user's profile Send private message 

Joined: 11 Dec 2007
Posts: 1026
Location: not Bulgaria

PostPosted: Wed 11 Apr 2018, 01:56    Post subject:  

Here is my own (long) take on what I'd like to see as a package manager in Puppy:

I have no doubt at all that the writer or writers of Puppy Package Manager (whatever version) have put in an enormous amount of work, which is well beyond what most of us would even be willing to attempt.

However... for those brave and dedicated enough to attempt any such package manager, I do have a view of what I at least think should be addressed, if possible (and it is surely true that most software desires are possible in some shape or form).

Number one for me is that a package manager should somehow or another have a mode that allows it to be run from the commandline. Indeed, I feel quite strongly that it is logical that commandline is the base mode of operation such that the GUI is only designed based on an already running commandline versio. One reason I say that is that if the main package management code can be used as an 'engine' with an API it allows developers to wrap the engine in whatever GUI they prefer.

Next is that the package manager should be flexible such that it can address all use cases needs or desires. For example, it should be possible to run it in a fully-automatic mode via suitable commandline switches. Without that is is useless as an engine for system admin scripting purposes, and that would be a huge limitation.

I read in some post or other someone worrying about security of automatic installations... well, automatic installation is quite the norm in the world of system admin. Of course, you wouldn't want that to be the package managers 'default' mode. By the way, you just need to look at pretty much any core-util in Linux, they generally have a force mode. For example, rm -rf ... you can destroy your whole system with that one if you are careless! But despite such force capabilities Linux has still not been abandoned!!! Despite the great efforts by some Puppy Linux developers, I suggest we should all look to larger projects to see what these very experienced larger teams of developers decide is appropriate. My own familiarity would be with Debian dpkg with apt. If we can accept that system provides a good exemplar for what facilities a Puppy Package Manager should provide then its design 'pattern' is no longer a problem - the only problem becomes best implementation:

For example:

The basis of managing lots of information about packages is to use some kind of database backend.

If the underlying package manager is designed as an 'engine' with an application interface, the exact design of any GUI is not of priority importance.

For use as a system admin tool, the package manager must be capable of being script driven. That means that any dialogs presented to users must be capable of being fully suppressed and there should be force options of varying strengths. For example apt provides the options (from its man pages):

-y, --yes, --assume-yes
Automatic yes to prompts. Assume "yes" as answer to all prompts and run non-interactively. If an undesirable situation, such as changing a held package or removing an essential package, occurs then apt-get will abort.
Only perform operations that are "trivial". Logically this can be considered related to --assume-yes. Where --assume-yes will answer yes to any prompt, --trivial-only will answer no
If any packages are to be removed apt-get immediately aborts without prompting.
Do not upgrade packages. When used in conjunction with install, no-upgrade will prevent packages listed from being upgraded if they are already installed.
Re-Install packages that are already installed and at the newest version.
-s, --simulate, --just-print, --dry-run, --recon, --no-act
No action. Perform a simulation of events that would occur but do not actually change the system.
-q, --quiet
Quiet. Produces output suitable for logging, omitting progress indicators. More q's will produce more quiet up to a maximum of two. You can also use -q=# to set the quiet level, overriding the configuration file. Note that quiet level 2 implies -y, you should never use -qq without a no-action modifier such as -d, --print-uris or -s as APT may decided to do something you did not expect.
Force yes. This is a dangerous option that will cause apt-get to continue without prompting if it is doing something potentially harmful. It should not be used except in very special situations. Using --force-yes can potentially destroy your system!

Note not only the warning message on --force-yes, but the fact that there are alternatives of somewhat less power that will often do. Basically, it is up to the system administrator, who is generally the one writing the system automation scripts and thus needs that flexibility. Yes, many Puppy users may not be at all skilled at commandline or system admin, but no one is being forced to type commands (dangerous or otherwise) anyway, and as I've said there are tons of 'dangerous' commands on every Linux system (and for very good system admin reasons).

By the way, I'm not meaning to suggest Puppy somehow adopt apt. Debian/Ubuntu already exists and DebianDogs already exist - these are Debian-based systems; they are not Puppy Linux. Rather I'm saying that Puppy, like all good distributions, is really only as good as the flexibility of its Package Manager and that PPM should offer similar (or hopefully better!) flexibility, including fully automatic scripting capabilities, as apt.

Finally, I have noted that sc0ttman has written a new package manager, which sounds interesting. Like many here who like to write our own system utilities, I am very interested to see how that turns out because many of my own plans require such a PPM to be available for my own programs to call up as and when required. I personally believe that a fully flexible package manager of the above-described sort is exactly what a good woof build system actually needs to have at its underlying core. My own makepup script is just a fudge to get round the fact that woof-CE has not been designed from the point of view of allowing it to be easily scripted/automated; better if it was too.

EDIT: I forget to add. Whatever package manager is written, I do hope it is written in a very modular fashion, because I have no doubt that package management is a very complex facility and the code will reflect that complexity. To be manageable and long-term maintainable modularity is important, but good clear documentation structure (and strict standards on how that structure is implemented/altered) for these modules is equally important otherwise it all becomes like an impossible maze to work out how it all hangs together and works... 10,000+ lines of spaghetti unstructured code is unlikely (I hope) to have a long future.

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [3 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum

Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0345s ][ Queries: 11 (0.0049s) ][ GZIP on ]