On Sun, 24 Feb 2013 20:01:56 +0000, Orchid Win7 v1 wrote:

>> The exception handling part is a feature of OO programming languages,
>> IIRC.  Bash scripting is far from OOP. ;)
> 
> I think exception handling predates OO. 

Well, I'm referring to things like catching exceptions.  That's something 
that IIRC came with OOP.

Prior to that, for example, in C, if you opened a file and then tried to 
do something with it if the open() call failed, you'd end up segfaulting 
unless you checked for an exception.

So I guess, in a way, that is "exception handling", but I'm talking about 
things like the Python "try:" method, or hooking failures.  You could 
kinda do it in various languages in various ways, but there wasn't a very 
standardized way to do it.

I may not be explaining it well. :)

> But whatever; Bash is a
> _scripting language_. It is meant for writing short, simple scripts, but
> building large, complex, mission-critical applications.

That I absolutely agree with. :)

Jim

Post a reply to this message

Am 24.02.2013 20:49, schrieb Jim Henderson:
> On Sun, 24 Feb 2013 12:21:51 +0000, Orchid Win7 v1 wrote:
>
>> On 24/02/2013 12:03 PM, Warp wrote:
>>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>>> I agree. However, unfortunately it seems that by default Bash ignores
>>>> all such errors and happily proceeds, unless you manually suffix every
>>>> single command with an explicit return-code check.
>>>
>>> How is that different from any programming language?
>>
>> In C#, Java or similar, if you try to open a file and can't, an
>> exception is thrown, and your program is halted. (Unless you thought of
>> that eventuality and coded a catch{} block for it.) In Bash, the program
>> continues to execute as if everything worked just fine, silently
>> ignoring the error.
>
> The exception handling part is a feature of OO programming languages,
> IIRC.  Bash scripting is far from OOP. ;)

Exception handling is not an OOP feature. And yes, bash /does/ have it:

   set -e
   trap "echo aborted by user || kill -INT $$" INT
   trap "echo aborted by other process || kill -TERM $$" TERM
   trap "echo error reported" EXIT

     ... critical section ...

   set +e
   trap - INT
   trap - TERM
   trap - EXIT

Post a reply to this message

Am 24.02.2013 21:01, schrieb Orchid Win7 v1:
>>> I agree. However, unfortunately it seems that by default Bash ignores
>>> all such errors and happily proceeds, unless you manually suffix every
>>> single command with an explicit return-code check.
>>
>> #!/bin/bash -e
>>
>> Have fun!
>
> I think you mean "set -e", but anyway...

Allegedly the above syntax is supposed to work, too. Provided of course 
that it's the very first line of the script.

Post a reply to this message

>>> #!/bin/bash -e
>>>
>>> Have fun!
>>
>> I think you mean "set -e", but anyway...
>
> Allegedly the above syntax is supposed to work, too. Provided of course
> that it's the very first line of the script.

According to the manpage I read, it's supposed to work anywhere in the 
script, so you can turn the feature on and off at will.

I especially love how set -e turns it ON and set +e turns it OFF. I 
think that's really special...

Post a reply to this message

Funny story, interesting that Linux works that way - I wouldn't have 
known that (but then it took me almost a week to get my bitTorrent 
client write access to an external hard drive under Linux).

> Fortunately, the fix is very simple. You just need to add a check for
> the possibility of there being zero devices.

I guess you can use this as a lesson to try and dream up some more 
possible failure modes (eg something else uses up disk space whilst you 
are installing, or ...). It only takes a half hour session and you might 
be surprised what other things you can't handle.

Also it would seem to me to make sense to have a "catch all" type check 
at the end of the installation (eg count folders/files or file sizes or 
md5 on the supposedly installed folder) to really be 100% sure the 
installation worked. At least then if it fails for some crazy reason 
you'll catch it.

> Also, somebody give that tester a medal. There's no way in hell we would
> have thought to actually *test* for such an obscure condition.

You shouldn't give him a medal then... just saying.

Post a reply to this message

> On 23/02/2013 10:24 PM, Francois Labreque wrote:
>
>> 1. Redirect stderr to a different file. And check for that file being
>> more than 0 bytes before claiming the install completed succesfully.
>
> Ooo, here's an interesting question - what is the size of /dev/sda? Is
> it the size of the special file, or the device to which it refers?

It's the size of the special file.  If you want to know the size on the 
device, you'll have to parse the output of df.

But that's not what I meant.  You redirect stderr to a file and then you 
check that THAT file's size is not zero with [ -s $ErrorLog ]

Come to think of it, you should also test that /dev/sba is a block 
device before trying to dd to it using [ -b /dev/sda ]



-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Sun, 24 Feb 2013 23:38:16 +0100, clipka wrote:

> Am 24.02.2013 20:49, schrieb Jim Henderson:
>> On Sun, 24 Feb 2013 12:21:51 +0000, Orchid Win7 v1 wrote:
>>
>>> On 24/02/2013 12:03 PM, Warp wrote:
>>>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>>>> I agree. However, unfortunately it seems that by default Bash
>>>>> ignores all such errors and happily proceeds, unless you manually
>>>>> suffix every single command with an explicit return-code check.
>>>>
>>>> How is that different from any programming language?
>>>
>>> In C#, Java or similar, if you try to open a file and can't, an
>>> exception is thrown, and your program is halted. (Unless you thought
>>> of that eventuality and coded a catch{} block for it.) In Bash, the
>>> program continues to execute as if everything worked just fine,
>>> silently ignoring the error.
>>
>> The exception handling part is a feature of OO programming languages,
>> IIRC.  Bash scripting is far from OOP. ;)
> 
> Exception handling is not an OOP feature. And yes, bash /does/ have it:
> 
>    set -e trap "echo aborted by user || kill -INT $$" INT trap "echo
>    aborted by other process || kill -TERM $$" TERM trap "echo error
>    reported" EXIT
> 
>      ... critical section ...
> 
>    set +e trap - INT trap - TERM trap - EXIT

Interesting, I didn't know that.  Thanks!

Jim

Post a reply to this message

>> Ooo, here's an interesting question - what is the size of /dev/sda? Is
>> it the size of the special file, or the device to which it refers?
>
> It's the size of the special file.

Figures.

> If you want to know the size on the
> device, you'll have to parse the output of df.

Only if the device is *mounted*. ;-)

I believe we used sdisk to do the job.

> Come to think of it, you should also test that /dev/sba is a block
> device before trying to dd to it using [ -b /dev/sda ]

Yes, that was the solution I chose in the end. It's an easy fix.

Post a reply to this message

>> Exception handling is not an OOP feature. And yes, bash /does/ have it:
>>
>>     set -e trap "echo aborted by user || kill -INT $$" INT trap "echo
>>     aborted by other process || kill -TERM $$" TERM trap "echo error
>>     reported" EXIT
>>
>>       ... critical section ...
>>
>>     set +e trap - INT trap - TERM trap - EXIT
>
> Interesting, I didn't know that.  Thanks!

It's truly terrifying just how much stuff you /can/ do with Bash.

(At this point I must remind you that just because you /can/ does NOT, 
in any way, imply that you /should/!!)

Post a reply to this message

On 25/02/2013 09:14 AM, scott wrote:
> Funny story, interesting that Linux works that way - I wouldn't have
> known that (but then it took me almost a week to get my bitTorrent
> client write access to an external hard drive under Linux).

Yeah. In the old days of Unix, there was a folder named /dev, and you 
used to run a command called mknod ("make node") which makes "files" 
which are really just ID numbers that tell the Unix kernel to access 
device X on bus Y. When you access, say, /dev/sda, you're really 
accessing the harddrive.

Windows does a similar thing, except it uses \\?\PhysicalDisk0 as the 
name. And this "file" exists if and only if disk 0 is actually plugged in.

Linux now uses a system called UDev. Instead of the OS installer running 
mknod to generate device nodes for every device that could ever be 
plugged in, the actual /dev folder is empty. The UDev software then 
dynamically creates the appropriate device node when I device is plugged 
in, and deletes it when the device is unplugged again. In this way, only 
nodes for devices that actually exist show up.

This is all very useful. But file redirection is such that if you 
redirect to an existing file, it is overwritten (the behaviour we want 
for our disk image), but if the file does /not/ exist, it gets created. 
And /dev isn't special; it's just a normal folder. The name /dev/sda is 
also not special; it's just a regular file.

All of this makes perfect sense really. It's just that if you tried this 
on Windows (i.e., tried to create \\?\PhysicalDisk7, say) it would tell 
you to go away and die. Linux, on the other hand, lets you do it just 
fine...

>> Fortunately, the fix is very simple. You just need to add a check for
>> the possibility of there being zero devices.
>
> I guess you can use this as a lesson to try and dream up some more
> possible failure modes (eg something else uses up disk space whilst you
> are installing, or ...). It only takes a half hour session and you might
> be surprised what other things you can't handle.

Oh I'm *sure* there must be other things that could fail. If the disk 
was scratched I'd expect some non-deterministic yet spectacular failure 
(not much we can do about that), if the target drive has bad sectors 
that'll probably silently fail too, pressing Ctrl+C will probably break 
something...

> Also it would seem to me to make sense to have a "catch all" type check
> at the end of the installation (eg count folders/files or file sizes or
> md5 on the supposedly installed folder) to really be 100% sure the
> installation worked. At least then if it fails for some crazy reason
> you'll catch it.

Fortunately, the install happens running under a Linux OS that I built. 
There are no other user applications running, and the user shouldn't be 
able to start any. (There's only one text terminal open, and you can't 
open any others.) But we'll see...

Post a reply to this message