Better command line tools, and pkg manager suggestions

[wiak]

Hi sc0ttman,

I presume you are still working on this? Does it handle package dependencies (via pet specs or whatever?).

Really needing a good package manager for automating Pup builds in similar way to what mklive-stretch DebianDog does on top of debootstrap using apt-get. (In Puppy would be commandline package manager additions after initial woof-CE minimal build - chroot into sandbox3/rootfs-complete and then package manager adds into that prior to squashfs and iso making).

wiak

[sc0ttman]

Hi sc0ttman,

I presume you are still working on this?

Very much so, doing a big clean up and a refactor.. making the code more testable, reliable, etc..

Does it handle package dependencies (via pet specs or whatever?)

Yes it does, works pretty well .. Pkg can install VLC from Slacko 14.2 repo, plus deps ,
which requires spanning multiple repos, some with packages in subdirs,
some not, some deps are PETs, some are .txz... but Pkg can handle it

But.. I am gonna rip out the dep resolution stuff and adapt PetGets code,
so that both package managers *always* return the same dep results..
(Pkg sometimes pulls in too many, and netsurf-3.3 (slackware-extra repo) makes
Pkg get stuck in a loop!!!

Really needing a good package manager for automating Pup builds in similar way to what mklive-stretch DebianDog does on top of debootstrap using apt-get. (In Puppy would be commandline package manager additions after initial woof-CE minimal build - chroot into sandbox3/rootfs-complete and then package manager adds into that prior to squashfs and iso making).

wiak

After more fixes and refactors etc, when it is safer to add new (testable) features,
I will work on being able to install into a different rootfs, so Pkg can 'provision' other
filesystems..

DESTDIR=/path/to/my/rootfs pkg [opts] PKGNAME

or

pkg --root=/path/to/my/rootfs [opts] PKGNAME

Alpine Package Manager can do this .. It's a nice feature.. I've made a list of all the nicest
features from other CLI package managers, plus a few I dreamed up ..

But I'm bugfixing and making it more reliable and easier to work on for now ..
The cleaner the code, the easier it will be to 'do it right' going into the future..

[wiak]

But I'm bugfixing and making it more reliable and easier to work on for now ..
The cleaner the code, the easier it will be to 'do it right' going into the future..

Absolutely. Too much code released in a hurry just cos it works (despite being hacked together and added to without careful modularisation etc). Well-designed clean code provides as you say for the future in terms of maintainability and enhancement. Development is always faster in the long (if not short) term if the programmer concentrates on getting the core code optimally designed.

wiak

[sc0ttman]

But I'm bugfixing and making it more reliable and easier to work on for now ..
The cleaner the code, the easier it will be to 'do it right' going into the future..

Well-designed clean code provides as you say for the future in terms of maintainability and enhancement.

I wouldn't ever call my code "well-designed" or "clean" lol, but I'm trying..

But I am going down the script, top to bottom (5000 lines of code), and I am
cleaning up each func (~ 70 of them at the mo), and :

* make sure each func only does 1 job, if possible
* making each func as small, readable as concise as possible
* good, simple, informative comments
* refactoring big funcs into smaller funcs
* simplifying any logic, removing any loops that aren't 100% necessary, etc
* replacing any repetitive routines/code with a single func for the job

I've fixed a bunch of things so far..

Pkg now reports exactly the same deps for pkgs as PetGet does (didn't have to steal PetGets code in the end)

Progress is decent .. Speed is OK, reliability is generally good ..
List of features is huge


I see Pkg often being used (by me at least) not just/only/even as a package manager (its main purpose) but as a dev tool, for easy making
of PETs etc .. Lots of useful command for Puppy users who make their own PETs and SFS files:

--download PKGNAME .... easier way to download PETs from any supported online sources...

--dir2sfs DIR ... make an SFS easily
--dir2pet DIR ..... make a PET
--pkg-contents PKGNAME .... get contents (file list) of any pkg
--pkg-repack PKGNAME .... (re)create a PET package from any installed packages
--pkg-combine PKGNAME ... auto-combine a pkg with its deps into a 'pkg-.1.2.3_ALL.pet'
--sfs-combine PKGNAME ... auto-combine a package and its deps into an SFS


Plus some useful debugging cmds:

--which FILE ... give file, find out which pkg it comes from
--which-repo PKGNAME ... give a pkg name, its repo its returned (if found in any supported repos)

.. and lots of PET conversion funcs ...
...many more...


But... I've received literally zero suggestions for "must have" or "nice to have" features,
other than yourself asking for Pkg to work inside Woof (a good one!)..
So I'll just make what I wanna make, see if anyone bites..

[wiak]

But... I've received literally zero suggestions for "must have" or "nice to have" features,
other than yourself asking for Pkg to work inside Woof (a good one!)..
So I'll just make what I wanna make, see if anyone bites..

Unfortunately, I've been so busy coding makepup I've not had time to check your package manager out yet. But I recognise the importance of getting a good/versatile commandline-based package manager for Puppy development, hence my encouraging you to progress it. Sometimes it is best to make a program the way that suits you best anyway, and once it is polished up a bit and stable, that's when further ideas will probably come in from users. Main thing is that it can be easily called up from other scripts, have flexible access to package repositories, and deal with dependencies as reliably as possible I feel.

I'll certainly be giving it a spin once I finally take a rest from makepup (only a few tiny extras I want to add to that for the moment - sometimes it is good to sit back and ponder for a bit before deciding on more...).

wiak

[foxpup]

But... I've received literally zero suggestions for "must have" or "nice to have" features, ...

I try to follow you sc0ttman, but I can not really. And I don't think you can beam me up.
It's very difficult to suggest something as a user noob. It's probably easier when you start to contribute yourself.

Tbh, I didn't use the ppm much, until I found out it resolves the dependencies for you. Before that I installed a pet/deb by double clicking it, used ldd or dependency check and went to the ubuntu repos for these libraries ... and so on. :/
You still have to go hunting for the dependencies if the pet/deb is not in the repos from the ppm.
So it would be a good idea that double clicking a package would install it offering to install the dependencies as well.
Or is that impossible to do? Then it still would be a good idea to point out that it is easier to install with the ppm from the repos from the ppm.

Something else I do: I gather all the packages needed (with the ppm), I unpack all the pet/deb and squash it into a sfs.
It's a bit awkward that you cannot see in ppm when/what you've "installed" by sfs. You also do not know whether some dependencies for your installed pets are met by a sfs; you better not uninstall the sfs then.

Do you know that mistfire supports a wide range of packages in his X-Slacko Slim?

[sc0ttman]

So it would be a good idea that double clicking a package would install it offering to install the dependencies as well.

Good idea.. Gpkgdialog (the GUI for Pkg) can (kinda) do it already , my Akita puplet had that feature - click on a PET in ROX, and if
that PET was found in a repo, then the deps could be auto downloaded/installed too

My current implementation is too slow and annoying - it searches deps as soon as you click on the PET..
A better way is to popup the GUI with a 'Get Dependencies' button ..
I will make sure to fix it up and make it work properly (if I can)...

Do you know that mistfire supports a wide range of packages in his X-Slacko Slim?

Thanks, I will have a look .. I didn't.. See what I can 'borrow'

*Currently* Pkg can work with packages from:

Puppy (.pet), Slackware (.tar.*, txz, tcz, tgz), Debian and Ubuntu (.deb), Arch (.pkg.tar.*), CentOS (.rpm), ...others??

... I used pkg to install mednfen from the Arch repo, worked fine.. Although I didn't test it fully..

It's a bit awkward that you cannot see in ppm when/what you've "installed" by sfs. You also do not know whether some dependencies
for your installed pets are met by a sfs; you better not uninstall the sfs then.

I have had the same thoughts ... It's awkward to have SFSs installed and the pkg manager knows nowt about them..

Pkg *could* be made to register SFS as installed packages, just like PET files.. Note made.. I will look into it, thanks.
It may break more than it solves though, will have to check it out!

Thanks for the ideas, will look at X-Slacko soon ..

Unfortunately, I've been so busy coding makepup I've not had time to check your package manager out yet.

I wouldn't bother testing the version I attached earlier, lots and lots has changed, feedback from it will be irrelevant now...

I'll certainly be giving it a spin once I finally take a rest from makepup (only a few tiny extras I want to add to that for the moment -
sometimes it is good to sit back and ponder for a bit before deciding on more...)

wiak

Makepup looks nice... I haven't even rebooted my puppy for like 4 days, so I'm not about to make a new puppy build, so can't test it yet..

My thoughts making a woof wrapper (which I might do straight after Pkg):

Should be a dialog based menu, like buildroot...

* choose base distro (gives the repos you will work with)
* choose kernel (the list u get depends on base distro choice..?)
* choose boot loader (syslinux, grub)
* choose defaults boot options, lang, keyboard, etc
* choose PET selection (if i can make Pkg and chroot play nice, Pkgdialog can seamlessly step in in here )
* choose desktop environment (apply various SFS [or PET collections])
* choose themes, wallpapers, etc (add the files, sed the configs)

Something like this (but simpler):



^ Notice the SAVE and LOAD buttons ... This lets you save and load your custom build config so that you (or others) can re-build one
of any previous builds that have been successful ...

Woof (makepup?) could save all the custom files, pkgs, configs, repo files, etc to a

./build/slacko_xfce4-6.9.9.9-k4.2.5.6/
./build/slacko_xfce4-6.9.9.9-k.4.41.6.22/

etc

..but probably such a "Woof-menu" would need to be a frontend to a CLI wrapper of the woof scripts.. not just a wrapper to woof itself..

Any chance of making a makepup menu based on dialog?

[wiak]

My thoughts making a woof wrapper (which I might do straight after Pkg):

Should be a dialog based menu, like buildroot...

* choose base distro (gives the repos you will work with)
* choose kernel (the list u get depends on base distro choice..?)
* choose boot loader (syslinux, grub)
* choose defaults boot options, lang, keyboard, etc
* choose PET selection (if i can make Pkg and chroot play nice, Pkgdialog can seamlessly step in in here )
* choose desktop environment (apply various SFS [or PET collections])
* choose themes, wallpapers, etc (add the files, sed the configs)

Yes, these would be very good options. I'd make it dialog and optional gtkdialog too (possibly yad option too, but that's not been so popular in Puppy itself). The user-interface can always be added to with alternative gui's anyway.

woof-wrapping isn't an easy exercise because woof scripts were designed for lots of manual choice entries so have to work round that. Maybe woof scripts could be slowly themselves changed to accept say a config file rather than only manual choice entries - easy to wrap then. It is notable how easy Debian debootstrap is to make a wrapper for, in building DebianLive-based distributions, since that is driven simply by commandline switches (e.g. for minimal install and so on), followed by simple chroot and use of package manager to add extras.

Anyway, for now at least, makepup is doing its wrapping job quite successfully so hopefully useful for both seasoned developers who don't want to enter same choices time and time again and as a simple route into using woof for the first time. Main thing I would like, when it comes to woof-CE itself, is for all the branches/distros to get tidied up - made to build perfectly by their creators (or whoever) and (as I've seen you also comment), moved into master branch as completed and ready. Also would like some new branch/distros build, which are less stuffed with packages, but perfect and ready for additions. (And maybe a much smaller sized Puppy branch built say out of slitaz package repositories).

wiak

[wiak]

@sc0ttman:

I notice you said you package manager was too slow in some functions. That is always the issue because so much searching in loops has to be done. Once you are satisfied with functionality you'll probably have to re-write some routines in C I expect. Indeed, some functions in woof-CE itself are done in C for that reason (unfortunately with some important info sometimes hard-coded in, which shouldn't be necessary I feel since C can be written to interact with values passed in from shell scripts and/or environment). Main thing is to get all functionality built in and working - optimising can always be done later of course, and if opensource, as I imagine it is, can be worked on by others especially if placed in github like facility.

Eventually, I will arrange makepup more usefully on github so others can add to it as desired - woof-CE is likely to be a moving target to wrap so maintaining makepup has to follow all woof-CE developments closely and eventually will be too much for me alone anyway.

wiak

[Pelo]

PPM Puppy Packages Manager is a nice tool, not perfect of course. Sometimes dependancies are missing like yesterday for Gramps for Unicornpup. But often PPM is Not Guily, missing dependencies are missing because not listed by Ubuntu.
If ever you really want an application that PPM fails to download well, with Slacko try Gslapt (Josejp2424 is fond of it)
For very new apps in Xenial, i use my XenialDOG;
Then after that, no idea.
PPM too slow, or not enough... well well well.. Let it as it is. Puppy users shall feed back if angry.. Devs don't mind generally about PPM. I use it daily..

wiak do you really need PPM, or it was only to underline that DebianDog system works fine ? Debian computers cannot be unchained. Laptops are serviceable indoor only.

Would you try to draw some Puppy passengers ? I use both OS (XenialDog and 360 Puppies, in my jukebox). Puppy users compile pets for the communauty, when Dogs will ask their passengers (Wireless) if they are any, to do it themselves.
We shall see when your live CD released if newbies happy with Debian Package management. Most newbies come from Windows, and never compute before, and don't want to begin. But i recognize that Dogs are really easy to use. Happy, Wiak ?

[wiak]

wiak do you really need PPM, or it was only to underline that DebianDog system works fine ? Debian computers cannot be unchained. Laptops are serviceable indoor only.

Would you try to draw some Puppy passengers ? I use both OS (XenialDog and 360 Puppies, in my jukebox). Puppy users compile pets for the communauty, when Dogs will ask their passengers (Wireless) if they are any, to do it themselves.
We shall see when your live CD released if newbies happy with Debian Package management. Most newbies come from Windows, and never compute before, and don't want to begin. But i recognize that Dogs are really easy to use. Happy, Wiak ?

Sorry, Pelo, I have really no idea what you are talking about, except, yes, I think sc0ttman's described new commandline-capable package manager would be very useful for Puppy systems. I have no plans to release any live CD (?) and doesn't bother me what the 'passengers' you describe do or don't do. Why should I? Anyway, I don't. Just use what you like (it is free afterall) and don't use what you don't like. You sound like you don't want developments - without it you will have nothing unless you buy Apple machine or Microsoft (or just use your android). Main thing is, have you nothing better to do than come on and complain about not getting things the way you want? Does complaining make you feel more important on Puppy community? It seems you are not alone. That's fine, but best if you don't do so on threads concerned with developing new things - the developers need space to focus on their work not listen to the ranters of whom there are too many (and growing in number for some reason it seems). People used to say how nice this forum was. I've been on it a long time, but truth is it is becoming quite painful doing developments on here - so maybe all developers should listen to you and just tell you how to get your wireless working (if possible) and not try to build better wireless tools so people have no such problems in the first case?

DebianDogs work well (and Debian helps a lot with that I think). As a developer, I think Fred is enjoying himself again (which is a good thing). I think he was beginning to not enjoy development work for a while before that, and not surprising. Me too, I left the forum altogether because so fed up of it, but had some unfinished work that interested me so came back with old group login ID. Toni became fed up too it seems, but I'm not sure if he is even developing anything new or not now. 01micko? - I don't know what his plans are - most developers seem to have vanished to a large extent into quietness (leaving the forum to the customer rants and argumentative trolls - who believe in conspiracies by opportunist 'alpha dogs' and malicious developer 'propaganda' - so ridiculous it's not funny). Indeed, I think a lot of people who used to develop are pulling back on doing so much development work and maybe will become an extinct species eventually. Then the forum will maybe work the way you want it, and people can help each other out all the time with what is left to play with. "Puppy customer forum". Ten years from now you can then enjoy using your ancient Puppy (and DebianDogs) of 2017! But not have developers to complain about (so what will you do to enjoy yourself then?).

Anyway, best to ignore all rants. I will stop ranting now cos I am only interested in improving Puppy because its survival as a creative OS distribution is of importance to me (for the moment anyway, but I get tired of the crap surrounding working on here). I don't agree that there is such a thing as a customer here or a passenger for that matter; there are just forum members enjoying using Puppy (and Dogs) for whatever reason they want to.

By the way, in case you don't know, I am developing 'makepup', which is 'just' a frontend of mine for using woof-CE to help build new Puppy distributions (dependent on what other developers add to woof-CE). Perhaps you think that has something to do with producing a DebianDog - No - it's Puppy-only. Maybe you confuse it with mklive-stretch by Fred - that's DebianDog in scripted form. Don't waste you time comparing - the systems have different good and bad points. If you want to discuss that maybe find a suitable topic area and start a thread for your nattering. If you are totally lost for an idea of something useful/productive today, why not take up the job of maintaining the Wiki - give it the LTS you demand - write it in French - really I don't mind - good to involve the international community more in my opinion. Someone would end up making a Polish, or German, or even English translation eventually I'm sure. Good Luck with that or the nattering...

wiak

https://github.com/wiake?tab=repositories
https://github.com/DebianDog

[foxpup]

@Pelo
You should read some posts of the first page of this thread to understand a little better what sc0ttman, wiak and other devs are trying to do here. They are essentially trying to make the building/processes of puppy better and to provide the tools for that.
I agree that PPM is working well in general. But it is strange that it is not command line and not at the base of building. Now it is just an app added to puppy. At least, that is how I understand it.

Pelo, please stop trolling, especially the devs that are working hard and with enthousiasm.

[sc0ttman]

I probably won't be trying to put anything in C... it's totally beyond me..
Despite the obvious benefits you mention wiak...

For better or worse(!) I will try to keep Pkg shell only..
Hopefully Pkg will live in the 'noarch' repo, with the same PET working on
x86, x64 and ARM... I hope!

Iguleder wrote a pkg manager for Puppy in C .. called packdude/packman/pack**someting** .. it's on his github page ..

You might wanna test that out before mine!
(Almost certainly faster and more reliable but limited features)

And yeah, it will live on GitHub, and hopefully some people will do pull requests (PRs) to add any fixes, updates etc
that they need to make it work on their puppy/OS ...


I have to get back another machine and get my github details and fix a few
things in the account first tho, so I can use it on any machine..

NOTE: Interesting approach to keeping it 'noarch' but still using bins:

src2pkg compiles some binary stuff that it needs when you run `src2pkg --setup` ..

[sc0ttman]

Just a note on this...

I felt sorry for the 14 people who have already downloaded Pkg ...
I've fixed sooooo many bugs I can only imagine how badly 0.9.0 is running lol
I probably scared them away forever from using Pkg..

But progress is decent.. Am fixing and fixing, not adding any new features yet...
I will upload what I have at the mo, just so ppl can try that one instead (if they like)..

I've cleaned up the code a lot, with lots of comments in it, although you will still find (lots of) bugs..

Still mostly tested against Slacko and slackware repos/pkgs...
Users of Deb/Ubuntu pups might still find Pkg "not working"...

So I'm keeping in 'Suggestions' for now, as it'll likely be buggy enough that users only
get a 'suggestion' of what Pkg is meant to be ..

So, if ur feeling brave, u can install the PET and then do something like this:

Code: Select all

pkg  # get a first run menu

pkg --update-sources # setup your lit of avail repos

pkg --repo-list # list all available repos

pkg --repo REPONAME # switch to chosen repo

pkg -n PKGNAME # search pkg names in current repo for PKGNAME (can also use `pkg --names` )

pkg -na PKGNAME # search pkg names in ALL repos for pkgname (can also use `pkg --names-all`)

pkg -s SEARCH # search all fields of repo

pkg -sa SEARCH # search all fields of all repos

pkg -ps PKGNAME # get pkg info (can also use `pkg --pkg-status`)

pkg -PS PKGNAME # get extra info (which deps are installed/missing)

pkg -g vlc # get (download+install) vlc and its deps (--get)

pkg -d vlc # download vlc only (--download)

pkg -i vlc-2.3.3-i586_s700  # install the vlc you downloaded (--install)

pkg -e vlc  # get (download and install) only the deps of vlc (not vlc itself) (--deps)

pkg -li # list user installed pkgs (--list-installed)

pkg -ld # list downloaded pkgs (pkgs in $WORKDIR, which is ~/pkg/ by default)  (--list-downloaded)

pkg -u PKGNAME # uninstall pkg  (--uninstall)

pkg -c PKGNAME # list contents of PKGNAME (--contents) .. must be installed/downloaded/builtin to get contents

pkg -w comm # find out which pkg the 'comm' cmd comes from (--which)

pkg -w /path/to/file # find out which pkf that file comes from (--which)

pkg -wr gimp-2 # find out which repo has gimp-2.*  (--which-repo)

# .. and with devx installed

pkg -pbl # list all available package build scripts (can also use --pkg-build-list)

pkg -pb PKGNAME # compile and package up a PET of PKGNAME (can also use --pkg-build)

and many more..

Or just type pkgdialog and get a nice menu that can do the above..

EDIT:

I haven't yet downloaded lots of Pups to add all their repos to Pkgs repo db...

So, to add more repos, open ~/.pkg/sources-all.

Look at the existing repo entries, then copy, paste & edit the existing entries as needed.

Then do `pkg --update-sources`

EXAMPLE REPO ENTRY in ~/.pkg/sources-all:

Code: Select all

puppy-tahr|pet|Packages-puppy-tahr-official|http://distro.ibiblio.org/puppylinux/pet_packages-tahr/||||noarch common trusty-main trusty-universe akita wary51x quirky 

The format is

#repo_name|pkg_ext|repo_file|ur1lurl2|url3|url4|fallbacks

The url1 field is required, other URL fields are optional mirrors..

('fallbacks' is the list of repo names (field 1) of other repos to fall back to, they can be installed on ur system, or not)

[Keef]

Installed it to Slacko and just tried a few of the examples above. No harm was done to man or beast. Got no suggestions so far, but the important thing is it working pretty well.
I've been contemplating doing some petbuild scripts, but have done nothing about this yet.

[Pelo]

foxpup , scottman is starting from zero something that yet exists...
but i would not stop you. I will keep away and just look.
The idea to load missing dependencies better than to list them is my goal too.
# gramps
/usr/bin/gramps: line 28: /usr/bin/python: No such file or directory
/usr/bin/gramps: line 28: exec: /usr/bin/python: cannot execute: No such file or directory
#
Gslapt is another tool , Josejp2424 comes back to it with Shiba Inu (32 and 64 bits) based on Slackware. But still missing libs to load manually.

┌─[root][01:42 AM][~]
└─[Shiba_Inu][$] gramps
Gdk, Gtk or Pango typelib not installed.
Install Gnome Introspection, and pygobject version 3.3.2 or later.
Install then instrospection data for Gdk, Gtk and Pango

[sc0ttman]

scottman is starting from zero something that yet exists...

No I'm not.. You don't understand this thread.

but i would not stop you.

Obviously..

I will keep away.

Yes please.

[sc0ttman]

Installed it to Slacko and just tried a few of the examples above. No harm was done to man or beast. Got no suggestions so far, but the important thing is it working pretty well.
I've been contemplating doing some petbuild scripts, but have done nothing about this yet.

Thanks for testing mate..

The dep checking and getting routines - the find_deps() and get_deps() funcs - could (should?) be replaced
with something faster and more efficient (Pkg is a bit slower than PetGet to resolve deps)..

Luckily, changing the dependency handling in Pkg means basically replacing those two funcs


EDIT: While I'm here, the list_deps() func is also involved... And it needs to be fixed to exclude builtins
from the list of deps it returns (currently, builtins are listed as deps, then skipped by other funcs...
but they should be excluded by list_deps() to begin with.. unless -F option was given)..

This is one of the first changes I plan to do.. Should make dep resolution faster and more reliable.
(and will pave the way for the added feature of optionally adding/removing builtins too, if -F was given)..


And about build scripts ... Well, you are one of the more experienced and advanced compilers
on this forum (you helped me many times with compiling and with kernel stuff) .. So, maybe just one or two that can
act as examples of how to build particular pkgs (PETs that need a source patch, for example, or whatever takes ur fancy) ...

.. to show people how's it's done..

Just a thought, obvs...

[sc0ttman]

As above, fixes in dependency resolution..

Changelog for 1.9.3

Code: Select all

- fixed default settings in rc file:
	# fix prevent correct dep search in first run
	# updated, DEPSEARCH='list_all_pkg_names' by default
	
- fixes in dep resolution:
	# much faster, less looping, checks fewer deps, more reliable:
	# now filtering out installed pkgs all in one go, in find_deps() and list_deps()
	# so `pkg --list-deps PKGNAME` now lists missing deps, not all deps.
	# the same for `pkg --pkg-status PKGNAME` .. only lists missing deps
		

[sc0ttman]

Changelog for 1.9.4

Code: Select all

1.9.4

- clean up in find_deps() and get_deps():
	# replaced some code in find_deps() with a call to list_deps()
	# cleaned up dep name validation, simpler, faster, less code in find_deps()
	# small cleanup in get_deps()
	# small cleanup in list_deps()
	
- fixes in /etc/bash_completion.d/pkg
	# fixed context sensitive TAB auto-complete results for
		--names-all(-na), --search-all(-sa), --names-exact-all(-nea)
	# fixed: added missing entry for txz2* cmds