The KnoppMythR5A10.iso has a but in /usr/local/bin/KnoppMyth-auto on line:608

There is an extra "$" inside the [] and in front of the SIZE var. Remove that and it should be fine.

Has no one doing development actually run the installer all the way through?

No, I just release it and hope for the best...

_________________
cesman

When the source is open, the possibilities are endless!

I am sure if there was a but in there someone would have smelt it! Are you sure you are not mistaken?


Hey I could use an extra $ or 2!


See had you left out this part your post would have been informative and helpful. With this part you just come across bad.

Well I'm not an expert in shell scripts, but I'm faily sure its a problem. The SIZE var is set in the same scope and I think it's not supposed to be referenced with a $... ?




not my intention to be rude, just pointing out that a test is in order.

There is a note at: http://knoppmythwiki.homelinux.org/inde ... ythInstall
that talks about the error and it is the line I'm speaking of, so I could be wrong about it.
Anyway, it certainly warrents a look from someone who is good with shell scripts.

FYI - I copied the KnoppMyth-auto script fromt he ISO to my /ramdrive dir and edited it; it then allowed me past that part of the script.

I looked. You're wrong. A quick test would have shown you that $[ EXPRESSION ] is equilvalent to `expr EXPRESION` if you're more familiar with that idiom for doing calculations..

The line in question is computing the disk size in (decimal) megabytes.

'Kay?

But thats that I'm saying!
Sould there be a extra "$" as in the lines below when X is in the same scope:
X=33; echo $[$X / 3];
rather than:
X=33; echo $[X / 3];

I wasn't trying to bring attention to the "[]" at all. WHen I di a quick test in the shell, both of the above work, however when done in the script the $SIZE var doesn't seem to exist and the expression becomes:
echo $[ / 3]

in fact if you execute that in your shell, you'll see that you get the same error output by the script... Which is strange because the SIZE var is set in the line just before the call.

From memory the code in question is roughly this:

The inner $ causes variable expansion, the outer one causes calculation expansion. I almost pasted the original in last night and did a full tutorial walk through picking it apart step by step (including the fact that using both grep and awk is silly since awk could do the pattern matching too), but figured it might be wasted effort.. I write lots of shell script these days, and code review more, so I have some expertise. Based on that expertise I'm telling you that it not only looks fine to me but did the right think when I cut it out and tested it.

I'm not much of a bash expert, but I am pretty handly at trial and error.

It seems the problem is that $SIZE is undefined. If this happens, than removing the $ fixes the error without changing the functionality (strangely enough).

I don't think this is a big issue as I don't think a zero size disk is going to install very well.

Who let this unintialized variable through code inspection anyway?

Allen

_________________
ASUS AT3N7A-I (Atom 330)
TBS 8922 PCI (DVB-S2)

I won't even go into how many ways that is NOT a fix. Here is the exact code in question:

SIZE is set on the immediately preceding line. Presumbaly DEV comes from a list of know devices and thus should always return a result. Checking that it got a result and providing an error message couldn't hurt, but really shouldn't be necessary unless you've done something silly with your hardware and /dev/hda doesn't have a size because it an optical disk.

BTW: would simplify the first pipeline above.

everyone knows how grep works (well almost) but the same can't be said for awk, so whilst your change has less characters in it, I find it less intuitive than the original.

Consider it a mind expanding exercise. In this case it doesn't matter since the enclosing function isn't called in a loop, but running two commands rather than three can make a difference in performance, and using awk can simplify stuff that's much harder and messier in shell.

No... Stop... No... My MIND.... It's... EXPANDING!!!

OWWWW!! It HURTS!!!

_________________
Do you code to live, or live to code?
Search LinHES forum through Google

Thanks for expanding my mind but I still like the first option better. It's not like in this case performance is even remotely an issue, and the first option just screams at you saying I'm searching for the line that has the disk we are looking for and then grabbing the fifth column from that line (which from the context I can see is the disk size). Now, anyone have tips on how I can fit this expanded mind back in my head?

P.S I like the awk tip though.

There is no way to fit your expanded mind back in your old skull. I'm afraid you're stuck with the Mojo Jojo exposed brain look now.

It could be worse, I almost posted my quick and dirty pgrep/pkill implementation (AIX doesn't have them) using only ps, awk and of course kill. It only has two rules and one of them is an END just so it exits with the right return code.