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 Thu 24 May 2018, 06:18
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Pet automation script to:
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [3 Posts]  
Author Message
mfb

Joined: 22 Mar 2016
Posts: 48

PostPosted: Mon 09 Apr 2018, 17:00    Post subject:  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 @
http://murga-linux.com/puppy/viewtopic.php?p=988065&sid=c22295ee9045d6809782dc49cada3e0c#988065
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:

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

Code:
petget /mnt/home/stretch/pet/youtube*
gtk-youtube-viewer
petget -youtube-viewer_3.3.1.pet
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1514
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
Code:
petget -q /mnt/home/stretch/pet/youtube*
gtk-youtube-viewer
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 
wiak

Joined: 11 Dec 2007
Posts: 652
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):

Code:
-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.
...
--trivial-only
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
...
--no-remove
If any packages are to be removed apt-get immediately aborts without prompting.
...
--no-upgrade
Do not upgrade packages. When used in conjunction with install, no-upgrade will prevent packages listed from being upgraded if they are already installed.
...
--reinstall
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
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.

wiak
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.0575s ][ Queries: 11 (0.0056s) ][ GZIP on ]