bbqsystool

[DebianJoe]

In a perfect world, I would like it to output all kernels and headers that are not in use currently.

The output from my current uname -r is 3.11-rc4-686-pae. When I use 'dpkg --list | grep linux-headers', I do get results for the 3.11-rc4 kernel.

Your line lists that correctly, Pidsley. The results I get back when using it on the 3.11-rc4 is the "common" files I pulled down with it, but aren't in use. I had expected similar results from the script (or script-section from the above) that Xaos had offered. My hope had been that it would work without relying on dpkg, and thus work on any vmlinuz.

It's not a major concern, but I don't know sed well enough (yet) to figure out how to make it do what I'd want...still, not a big deal. What I have works as advertised. I may take some time to study sed \/\/\/\/\/\/ in better detail.

[xaos52]

Joe,

Would you mind running kernel.sh with tracing enabled:

Code: Select all

sh -x ./kernel.sh |& tee kernel.sh.log

and post kernel.sh.log

The 'pidsley' script should not give you any header files if you modify it to:

Code: Select all

dpkg -l|awk '/^ii linux-im/{print $2}'|grep -v $(uname -r)

Let me explain the awk bit a bit more:
/^ii linux-im/ is a regular expression
^ is an anchor to the beginning of the line
so awk will print all lines starting with 'ii linux-im'

In the original expression from pidsley
sudo apt-get remove $(dpkg -l|awk '/^ii linux-(im|he)/{print $2}'|grep -v $(uname -r))
has
/^ii linux-(im|he)/ as regex
the (im|he) part of it means 'im' or he', so it selects both images and headers.

[xaos52]

The ACTUAL variable is not set in the script I posted.

This is what happens if you quickly cut & paste an existing shell script to create a new one.

Replace the main part of the script by

Code: Select all

ACTUAL="$(uname -r)"
get_KernelList
for kernel in $KernelList; do
    echo $kernel
done

And it will filter out the kernel you are actually booted into. No need for 'grep -v $(uname -r)' any more.
If you want the kernels on one line, remove the for loop and replace it with
echo $KernelList

[xaos52]

What my script - in fact it is siduction's script - does more is this:

If it finds a kernel, it checks if the kernel is a dependency of a meta kernel package. If it is, it won't remove the kernel, because the remove would conflict with the dependency.
Only if the kernel is NOT a dependency of an installed meta package, then it will list that kernel for removal.

That probably explains why you got no output from my script. Your kernel package is a dependency of the meta package linux-image-686-pae.

I think it will be hard(er) to generalize this to systems with non-Debian package system: you could find kernels that were not installed via the Debian package manager (or via rpm or another package manager) and you would not know how to remove them correctly.

[DebianJoe]

Thank you for the clarification. For all that I know of different programming languages, I can assure you that I'm very new to the process of using awk and sed with shell scripting. I have much to learn before I feel comfortable using them without having someone else double-check me.

You're absolutely correct on the dependency regarding the 3.10-2-686 kernel, as '+ grep-available -F Depends linux-image-3.10-2-686-pae -s Package', appears during the sh -x ./kernel.sh |& tee kernel.sh.log output.

I see the relation between the ( || ) in C and the( | ) with awk, so thanks for the extended explanation. I have that now, albeit the lack of a wildcard character is interesting for partial words.

I will have to spend more time at looking at all possible manners of kernel installation across distros before I am comfortable with trying to make it totally distro agnostic.

Once again, I really appreciate the expertise you have both offered regarding shell. For everything that I attempt to make happen, even if it exceeds what I'm able to pull off...I learn new and exciting things.

An addendum: I DO wish to have the corresponding headers for each of the images removed. I don't see any benefit to leaving them just sitting around if they aren't being used. Am I mistaken about the potential benefit to having them? I cannot come up with a single good reason to not remove them along with a deprecated image.

[xaos52]

I don't see why one would keep stale header packages around either.

[DebianJoe]

Perhaps the best way to explain why my requests are so specific is to check out the package that I'm trying to integrate the shell scripting into.

The idea is to simply walk the user through options for CPU, kernel, and kernel removal settings. I want them to have more control, and eventually be able to not need the very short "tutor" section at all. If it comes down to using a larger shell script to automate everything for the user, then I would much prefer to use the language that it is programmed in to automate the process than to have a separate script to be executed.

I wish to teach the user to fish, rather than just feeding them on a regular basis. I'm not sure why I like that idea, but it seems like a good one. Give the power to the user to know that they really don't need you to automate everything for them...it's what I'd like to see more of.

Edit: ....and I am not very good with more advanced shell scripting, yet. You guys are starting to make me really wish to know more.

[DebianJoe]

Pushed most recent changes to bbqsystool, cleaned up some things...added pmap by pid for tutorial mode.

Taking a few days to learn how to use shell scripting, because I don't like asking questions...especially when I have to research the answers to figure out why they do what they do.

Test the tool, report back with issues/suggestions/general complaining/etc.

[xaos52]

a couple of days heh?

if you want to develop some decent scripting shells - bash, sed, awk, ... - I don't expect to hear back from you this year

BTW: found a small problem with the program: resizing the terminal window won't refresh the screen and you end up with some boxes being drawn and staying on screen. Bit ugly.

It occurs when you start with a term window that is too small to fit the output of bbqsystem and then enlarge the term window, like in this scrot - made with the latest version pulled from your repo.

[DebianJoe]

Thanks for that Xaos. I use a dwm with a 1/2 screen urxvt or a pretty large urxvt with cwm...so I hadn't tried that yet. I'll probably do a check like ceni does to let you know to have at least a certain frame-size before you launch into curses.

If resizing causes issues, I should be able to use the column/row figures to poll regularly, so if that changes...to instantly refresh().

If you run across anything else, toss it my way.

Edit: A couple of days is relative. It won't ever end, most likely. I tend to pick up a new thing, and just improve the more that I use it. "A couple of days" is in reference to a couple of highly-focused days of not doing anything BUT that.

2nd Edit: ...and so far, I've said "I didn't know that," at least 20 times.

[machinebacon]

Funny, I thought of "check the window like Ceni", too - and checked the script -- haven't found the function to check for screen size (anyway Ceni is perl)

[DebianJoe]

Luckily, this is C and not bash...so I've got this sans examples. ;)

Fix pushed to master branch that cleanly exits if term size isn't at least 60x22, even if it is resized during run. It also let's user know (in bright 1;31m) the needed size of the window. Only exits under main-menu, so if it was resized after dropping into the shell sections, if they put it back...it can continue to run.