Life at the CLI

I’ve been trying to clean up the syntax for SINP and I’ve discovered that I needed to overhaul the way command line options were handled. I decided to have the -options set flags then use the other argument for searching/downloading. Hopefully this will give SINP greater flexibillity. Because of this I’ve got to overhaul how most of the functions work, but it will be worth it if SINP can have cleaner syntax. Usually this is the point where I start the project over from scratch, but that always leads to having a million copies of the same file lying around. Guess it’s time to learn how to properly maintain an application.

I did some cleaning up of SINP last night, and the searching function is complete. You can now use SINP to search the slackbuilds.org by application name (default) or by the descriptions in the SlackBuild’s README and slack-desc file. Description searching takes a loooooong time mainly because wget hangs on every couple of files. It looks more like a server problem than with SINP. When SINP’s not stuck it usually reads the descriptions pretty fast. Unfortunately description searching sometimes gives false positives. For example if I’m searching for the word term, probably searching for some terminal application, returns stuff if term is found in any word in the description. (like determine)

Maybe this could be fixed by requiring a match in both the README and slack-desc files, or maybe I could just learn grep better.

Also, in the future I’d like to be able to use more than one keyword for description searching, but for now I’m completely happy with my results and have submitted the project to sourceforge.net for review. So in a couple of days I should have a nice place to host SINP and a skeleton website up.

There was some interesting talk on the ##slackware channel about someone running a portage on Slackware. It’s a cool idea to think about, so I decided to rig up a script to integrate SlackBuilds from the slackbuilds.org project with Slack’s native package manager. The result is SINP. Unlike portage SINP is not a package manager. All it does is download SlackBuilds, run the SlackBuilds, and install the resulting package. And in true Slackware fashion it does not track dependencies. This means that there is no local database that you have to keep updated, and you don’t have to worry about a broken database that winds up corrupting everything. (as has been my luck with from source distros)

The script isn’t nearly as polished as it will be, but it gets the job done, and it needs to be run as root.

Usage:
./sinp -s something searches slackbuilds.org for whatever something is.
./sinp -d something downloads the SlackBuild tarball
./sinp -p tells sinp to actuall run the SlackBuild

and finally ./sinp -i full_path_to_package calls installpkg to install the new package

When using -d I recommend having the argument as (including the quotes) `./sinp -s whatever` because that’s the format the download function needs. FOR NOW

Also when using -i you need to put the full path to the tgz file. Again, something that will be cleaned up.

A full run (download, make package, install package) for supertux would look like ./sinp -d `./sinp -s supertux` -p -i /tmp/supertux*.tgz

When all the smoothing out is complete it should look like ./sinp -dpi supertux

I’d like to eventually host the project on a Slackware specific site, but sourceforge would be OK.

If you’d like to try it out the script is the first comment. Any feedback is welcome.

Through my own stupidity and lack of organization I have managed to duplicate a large mass of files over the years. These duplicates are scattered all over the place and aren’t guaranteed to be in the same directory from backup disk to backup disk. Also some of the backups are more recent backups so the files contents are somewhat different. Then there’s the horror of duplicate tree’s within duplicate trees from attempts to organize the mess! (not to mention duplicates that have been compressed and projects that have been duplicated to rework) There’s several gigs worth of data that I’d like to salvage in there! Surely someone has made a tool to deal with this type of situation. I’m currently trying some apps found on freshmeat.net to see if there’s anything at all to help.

I need something that can
find exact duplicated - md5 hash?
find similar duplicates and be able to view differences/merge contents- files that have been updated
and finally, files with the same name that have the same name, but are completely different
cross platform would be nice

Then I have my paper stacks to digitize, but I’ll save that for another day

For a lot of small scripting projects and everyday stuff I find myself redirecting the output of some command to a file (usually called tmp/tmp?) for different purposes. This is perfectly fine. I know that if I come across a file called tmp it’s usually safe to delete, but having a bunch of “tmp” files left lying around undeleted just adds to the clutter in my $HOME. (Not to mention all the wasted KB’s of hard disk space ) Then it occurred to me that the sole reason for /tmp’s existence is being a place to store temporary files. So this year one of my New Years resolutions is to keep all these “tmp” files in /tmp where they belong.

watch runs command repeatedly and updates the output on the screen. This is useful for monitoring the output of a command, like cat $LOGFILE, for changes. This allows for all sorts of scripting goodness. Guess that means I have another excuse to have an xterm open.

It’s been a while since I’ve used CSS. For just about all my recent web pages I’ve relied on font tags and tables, and most probably weren’t valid HTML. (GASP!) It’s fun to watch the whole page magically update with a change in a single file.

After being reinformed about slackbuilds.org I started polishing up my SlackBuild template. My first attempt to submit something was a flop because someone beat me by about a day. After this I decided to repolish my SlackBuild template (which I’ll admit was a little rushed towards the end) and now I finally have something I can live with. The new template should work with most programs with minimal tinkering, and looks like will integrate nicely with the new packager user I’ve been dreaming up. Anyway, I hope to have a new script submitted (and accepted ) by the end of the day.

My customizing Slackware rampage has led me to three nice Linux wikis.

• Arch wiki - A good resource with lots of good content
• Slack wiki - Not a lot of content yet, but it’ll grow
• Gentoo wiki - Nicely catagorized, Gentoo has always been well documented

I messed up my Slackware partition again, so I decided to give Arch a try. I can only give a comparison of the installer because, well, that’s about as far as I get.

The installers, at first glance, look very similar. Both use the same style installer, but the Slackware one is a little simpiler. This first difference that you’ll come across is the hard drive preparation. Slackware asks you to prepare your partions before running the setup program. Then once you start the install program you select your swap and / partitions, followed by formatting options. Arch on the other hand includes partitioning, and formatting in the same menu option in the install program. When using the Slackware installer you can select advanced formatting options like bad block checking and inode density. Arch just goes ahead and uses the defaults.

Next comes the package selection. Slackware show’s a list of package groups to install. This is the same for Arch. After group selection Slackware lets you pick the way the actual packages are installed. Full mode installs everything. Newbie prompts for every package except critical ones, and menu and expert allow you to select packages for each group from a menu. Slackware also uses tag files to control what packages are selected by default. Arch gives you a giant list of packages after group selection that are either all selected or none selected, with the exception of packages from the base group which are always selected. Slackware prints nice little descriptions of each group and package while they’re installing. Arch does not.
After package selection comes package installation. (This is the part I find most annoying about Arch) This is a separate menu option on Arch. Arch’s package manager (pacman) keeps track of dependancies, so if a package is missing or causes a conflict pacman let’s you know about it. The only problem is that when you do experience a conflict you aren’t given an option to resolve the conflict. The only way to resolve the conflict is to find the conflicting packages in the long list and select the one you want. If you have more than one conflict you have to repeat this process. Slackware installation packages are configured to not cause conflicts. (at least that I can tell)

… Sorry, it’s been a while since I started writing this. I forget what comes after this part of the Arch install. (Guess that means I need to try Arch again ) Arch is not a bad distro, in fact I would probably love it if I could get a working system. With Arch you should really read the instructions before doing the install.

All you Arch users have my undying respect, and I’ll get past the install someday. Until then, keep updating your wiki, and I’ll keep looking up stuff on it for Slackware