×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fault Tolerant Shell

michael posted more than 10 years ago | from the does-it-correct-typos? dept.

Programming 234

Paul Howe writes "Roaming around my school's computer science webserver I ran across what struck me as a great (and very prescient) idea: a fault tolerant scripting language. This makes a lot of sense when programming in environments that are almost fundamentally unstable i.e. distributed systems etc. I'm not sure how active this project is, but its clear that this is an idea whose time has come. Fault Tolerant Shell."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

234 comments

U think so? (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8566844)

Nope, you didn't

falt tolerance a la MS IE (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8566847)

then we will end up having 60% of all shell scripts unusable in standards-compilant shells

Python (2, Offtopic)

derphilipp (745164) | more than 10 years ago | (#8566848)

Also, I would appreciate (not quite the same) a auto-completing python interpreter and editor (which can complete methods and objects from modules)... Such kind of stuff really increases productivity !

Re:Python (5, Insightful)

Noryungi (70322) | more than 10 years ago | (#8566882)

a auto-completing python interpreter and editor

Try the Wing IDE [wingide.com]. It has most of the functions you wanted... But it's not free software.

(offtopic, but..) Python (1, Informative)

Anonymous Coward | more than 10 years ago | (#8566889)

auto-completing python interpreter and editor

An auto completing Python interpreter and editor:

Pythonwin [python.net] (Windows only).

When it expands a class or module, select the one you want with the up and down arrows (or just keep typing to narrow the selection down), then press tab to select it.

Fault Tolerant Spanking The Monkey (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8566854)

Roaming around my school's locker rooms I ran across what struck me as a great (and very pubescent) idea: a fault tolerant spanking the monkey. This makes a lot of sense when masturbating in environments that are almost fundamentally unstable i.e. school toilets etc. I'm not sure how active this project is, but its clear that this is an idea whose time has cum. Fault Tolerant Spanking The Monkey.

First Real Post (-1, Offtopic)

Saint Stephen (19450) | more than 10 years ago | (#8566855)

I think this is a fantastic idea. It's a wonderful idea, and I wonder why nobody thought of it before.

I didn't say it was the first Good post.

You're dealing with the problem too high up (5, Interesting)

phaze3000 (204500) | more than 10 years ago | (#8566856)

IMO (as someone who works on clustered systems for a living) you're looking at this from the wrong point of view. A clustered shell is useful only if the system it is running on top of is inherently unstable.

The real benefit is in having a system which is sufficiently distributed that any program running on top of it can continue to do so despite any sort of underlying failure.

Re:You're dealing with the problem too high up (5, Insightful)

unixbob (523657) | more than 10 years ago | (#8566919)

Doesn't that depend on the definition of clustered though? Clustered systems can be things like beowulf clusters. But often a collection of standalone web servers behind a http load balancers is commonly referred to as a web cluster or array.

IMHO as someone who works in a complex web server / database server environment, there are many interdependancies brought by different software, different platforms and different applications. Whilst 100% uptime on all servers is a nice to have, it's a complex goal to achieve and requires not just expertise in the operating systems & web / database server software but an indepth understanding of the applications.

A system such as this fault tolerant shell is actually quite a neat idea. It allows for flexibility in system performance and availability, without requiring complex (and therefore possibly error prone or difficult to maintain) management jobs. An example would be server which replicates images using rsync. If one of the targets is busy serving web pages or running another application, ftsh would allow for that kind of unforeseen error to be catered for relatively easily.

Re:You're dealing with the problem too high up (2, Insightful)

Moderation abuser (184013) | more than 10 years ago | (#8567069)

"An example would be server which replicates images using rsync. If one of the targets is busy serving web pages or running another application, ftsh would allow for that kind of unforeseen error to be catered for relatively easily."

It depends how you organise your systems. If you push to them then yes you need something like ftsh. If you organise them so that they pull updates, pull scripts to execute and arrange those scripts so that they fail safe (as they all should anyway) then you'll have something which is a couple of orders of magnitude more reliable and scalable. It just needs a little more thought to begin with.

Re:You're dealing with the problem too high up (2, Insightful)

unixbob (523657) | more than 10 years ago | (#8567155)

Well that was just an example. If on the other hand the system the images were pulled from was very busy then the same is true. The problem is that you can't architect for a moving target and the flexbility that rapidly changing environments require is something which ftsh would be quite useful for.

Re:You're dealing with the problem too high up (-1, Troll)

Oligonicella (659917) | more than 10 years ago | (#8567231)

Your hero didn't even address all the errors and outright lies pointed out about his movie 'documentary'. He's still a liar, chum.

Re:You're dealing with the problem too high up (0, Offtopic)

ChuyMatt (318775) | more than 10 years ago | (#8567477)

Does admitting that many of the things he says are right scare you? Yes, if you watch the movie once, you realize that he is slanted in his view. NOT A BIT SURPRISING!

I was skeptical also, but he touched on almost every source that i found, just looking on the internet and not including the defamation sites. You, sir, seem like you are desperately looking for a reason not to believe ANYTHING that the movie says. Being someone who has been shot at and lost school friends to nutters with guns, i simply cannot reject the truths that are in that film.

Bad Idea (5, Insightful)

teklob (650327) | more than 10 years ago | (#8566863)

It's a well meaning idea, but it would cause more problems than it would solve. It would just encourage sloppy code; people would rationalize "I don't need to fix errors because it doesn't matter", which is a very bad habit to get into when programming, ignoring errors, or even warnings

Re:Bad Idea (2, Interesting)

Anonymous Coward | more than 10 years ago | (#8566923)

Well, your idea is well-meaning, but it is a bad idea to cling too closely to the principle of fixing all bugs first. It is a fact of life that some bugs will remain however hard you try (even formal proofs won't notice specification errors), and in a critical production system you need to have some robustness against failures. It's no good if your system up and dies the moment it hits a real bug. IMHO a fault-tolerant shell will be a useful tool in some situations, even if some people end up misusing it.

Re:Bad Idea (5, Insightful)

Tx (96709) | more than 10 years ago | (#8566948)

I agree. Web browsers were designed to be fault tolerant, and just look at all the horrendously broken crap that passes for HTML out there. Dangerous stuff.

Re:Bad Idea (2, Insightful)

Androclese (627848) | more than 10 years ago | (#8566981)

Exactly, you nailed it on the head!

The only thing I can add at this point is an analogy:

Think of it along the lines of IE and HTML; if you don't want to close your tags, say your table td and tr tags, it's fine, the IE browser will do it for you.

Nevermind that it will break most any W3C compliant browser on the planet.

(insert deity here) help the person that gets used to this style of programming and then joins the real world.

Re:Bad Idea (3, Interesting)

Yakman (22964) | more than 10 years ago | (#8566991)

hink of it along the lines of IE and HTML; if you don't want to close your tags, say your table td and tr tags, it's fine, the IE browser will do it for you.

According to the HTML 4.01 spec [w3.org] </td> and </tr> tags are optional. So you can code a standards compliant page without them, as long as you declare your doctype properly.

Re:Bad Idea (1)

unixbob (523657) | more than 10 years ago | (#8566982)

OTOH, if the tool makes scripts simpler then bugs are less likely to be introduced. Why do we all need to keep on reinventing our own libraries and methods for checking an NFS server hasn't timed out (to use the example on the ftsh site). why not use a tool that does that stuff for us so we can concentrate on writing more elegant and functional scripts that are easier to read and debug and quicker to write.

Missing the point (4, Insightful)

SmallFurryCreature (593017) | more than 10 years ago | (#8567033)

This is not about catching scripting errors. It does not fix your code. It is about catching errors in the enviroment that scripts are running in.

Shell scripts should be short and easy to write. I have seen plenty of them fail due to some resource or another being temporarily down. At first people are neat and then send an email to notify the admin. When this then results in a ton of emails everytime some dodo knocks out the DNS they turn it off and forget about it.

Every scripting language has their own special little niche. BASH for simple things, perl for heavy text manipulation, PHP for creating HTML output. This scripting language is pretty much like BASH but takes failure as given. The example shows clearly how it works. Instead of ending up with PERL like scripts to catch all the possible errors you add two lines and you got a wonderfull small script, wich is what shell scripts should be, that is none the less capable of recovering from an error. This script will simply retry when someone knocks out the DNS again.

This new language will not catch your errors. It will catch other peoples errors. Sure a really good programmer can do this himself. A really good programmer can also create his own libraries. Most find of us in admin jobs find it easier to use somebody elses code rather then constantly reinvent the wheel.

Re:Bad Idea (4, Interesting)

cgenman (325138) | more than 10 years ago | (#8567167)

It's a well meaning idea, but it would cause more problems than it would solve. It would just encourage sloppy code; people would rationalize "I don't need to fix errors because it doesn't matter", which is a very bad habit to get into when programming, ignoring errors, or even warnings

The same logic could be applied to any security system, from the automatic door lock on the front of your house to Airbags in your car. Spell checkers discourage people from learning to spell. Antibiotics prevent the growth of the immune system. Why have a lock on your trigger, if it will encourage you to leave it in a place where your kids can find it.

The fact of the matter is, if the code works, it's good code. This is a shell scripting language we're talking about here... Not exactly assembly. Programmers would be better off spending more time thinking about the higher structure of their applications and less time hunting down trivial mistakes.

Of course, I know that this isn't quite what the article is talking about, but it's the principle of the thing. Augmentation would be an improvement.

Oooh! An idea whose time has come! (2, Funny)

linuxbaby (124641) | more than 10 years ago | (#8566867)

More ideas whose time has come [google.com], including:
  • DRM Helmets
  • Jack Kemp
  • Yankee Go Home
  • Collaborative Dispute Resolution
  • Microchips for Your Pet Parrot! (see page 2 of Google results)

Re:Oooh! An idea whose time has come! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8566940)

WOW!!!

You mean to tell me that since 1997 the idea to chip parrots has been around and yet there are still poor, defenseless, unchipped parots in the world wondering what slings and arrows will be thrust at them next?

I say it is time we chip the bird for everyone!!!

AND...

You can help by sending check or money order to:

John Q. Public
123 Main Street
Anytown, USA

Any contribution will go a long way in making sure these parots who time has forgotten finally get thier chance to chipped and thereby protected.

(No, this has nothing to do with the script; just like to point how google's keeps **current** content.)

Wouldn't be much work in Tcl (4, Interesting)

DavidNWelton (142216) | more than 10 years ago | (#8566879)

... or probably Perl or Python, either.

It doesn't actually seem to grok the commands that are being run, so something like

proc try {times script} {
if { [catch [uplevel $script] err] } { cleanup ; retry }
}

is all that's needed (of course to do it right you'd need a bit more, but still...).

try {5 times} {
commands...
}

Although Tcl is a bit lower level, and would require you to do exec ls, you could of course wrap that too so that all commands in the $script block would just be 'exec'ed by default.

In any case, better to use a flexible tool that can be tweaked to do what you need then write highly specialized tools.

Re:Wouldn't be much work in Tcl (2, Insightful)

patSPLAT (14441) | more than 10 years ago | (#8567393)

Here's a Ruby one:

def college_try (limit, seq =0)
begin
yield
catch e
# forgot the syntax for getting the block
college_try( limit, seq + 1, block ) if (seq < limit)
end
end

college_try( 50 ) {
begin
do some work
catch e
do error clean up here
raise e
ensure
do cleanup that should always run here
end
}

Anyways, I agree with the notion that most popular scripting languages have advanced error handling that is up to the task.

Worst idea since spell checkers (4, Insightful)

91degrees (207121) | more than 10 years ago | (#8566884)

This will not improve people's skills. In fact, it willl make them more prone to mistakes, and more likely to get the result that they didn't expect. It's similat to computer spell checkers. Ever since people started relying on these, their spelling has gone way downhill simly because they don't bother thinking. Computer do all the spelling for them. They don;t need a spell checker. They need spelling lessons.

This si even worse. Computers will try to second guess what the user means, get get it wrong half tyhe time.

A qualified shell scripter will be not make these mistakes in the first place. Anyone who thinks they need this shell actually just need to learn to spell and to ytype accuratly.

Re:Worst idea since spell checkers (0, Insightful)

Anonymous Coward | more than 10 years ago | (#8566907)

Was that a joke post?

Re:Worst idea since spell checkers (5, Funny)

FrostedWheat (172733) | more than 10 years ago | (#8566918)

just need to learn to spell and to ytype accuratly. -- QED - Quite Easily Done

<Teal'c> Indeed </Teal'c>

Re:Worst idea since spell checkers (1)

bkhl (189311) | more than 10 years ago | (#8566973)

Ever since people started relying on these, their spelling has gone way downhill

I find that hard to believe. Rather, I'd say my impression is that spelling has never been as standardised as it is today. What did you get that from?

RTFA (2, Insightful)

Anonymous Coward | more than 10 years ago | (#8566974)

You obviously didn't read the article.

"It [ftsh] is especially useful in building distributed systems, where failures are common, making timeouts, retry, and alternation necessary techniques."

It doesn't protect you from typos in the script, it handles failures in the commands that are executed.

Re:RTFA (1, Funny)

91degrees (207121) | more than 10 years ago | (#8567019)

Of course not. I'm trolling. Details like facts get in the way.

Re:RTFA (0, Offtopic)

ichimunki (194887) | more than 10 years ago | (#8567062)

Best part is: you've been modded up to +4, Insightful. Makes a person wonder if Slashdot isn't actually a Diebold beta of some sort.

Re:Worst idea since spell checkers (0)

Anonymous Coward | more than 10 years ago | (#8567002)

MS Word spellcheck for your first paragraph:

This will not improve people's skills. In fact, it willl make them more prone to mistakes, and more likely to get the result that they didn't expect. It's similat to computer spell checkers. Ever since people started relying on these, their spelling has gone way downhill simly because they don't bother thinking. Computer do all the spelling for them. They don;t need a spell checker. They need spelling lessons.

Re:Worst idea since spell checkers (2, Interesting)

Air-conditioned cowh (552882) | more than 10 years ago | (#8567216)

Personlly, I think my spelling has improved due to spell checkers. I allways try to learn from whatever corrections is makes. Maybe other folks do too.

Also, this isn't about covering up mistakes. I am sure good script programmer will _allways_ assume a command can fail. Using the example of the "cd" command in the article, should I really just assume it worked before removing files? Of course not. How ftsh helps is that the necessary error checking code is made more readable and brief. I still have to trap errors whether I use ftsh or bash, the difference is ftsh is easier to understand.

Simply making code less convoluted and more readable is not the same as sloppy programming.

Re:Worst idea since spell checkers (1)

ArseneLupin (743401) | more than 10 years ago | (#8567516)

This si even worse.

Ha!

Anyone who thinks they need this shell actually just need to learn to spell and to ytype accuratly.

Somehow I get impression that these inaccuratl msiytypings are intentional. My bad.

It's got the concept backwards (4, Insightful)

Moderation abuser (184013) | more than 10 years ago | (#8566893)

While, yes, you manage distributed systems from the center, you don't *push* updates, changes, modifications because, it doesn't scale. You end up having to write stuff like this fault tolerant shell which is frankly backwards thinking.

Instead, you automate everything and *pull* updates, changes, scripts etc. That way if a system is up, it just works, if it's down, it'll get updated next time it's up.

I won't go into details but I'll point you at http://infrastructures.org/

Sounds like good way to do some serious damage (2, Interesting)

heldlikesound (132717) | more than 10 years ago | (#8566894)

on a loosely configured network, not saying this tool doesn't seem interesting, but it seems prone for use in DOS attacks...

This would be nice... (5, Insightful)

Ritontor (244585) | more than 10 years ago | (#8566901)

how many times have you hacked something together in perl that ended up being relied on for some pretty important stuff, only to find 6 months down the track that there's some condition (db connects fine, but fails halfway through script execution as an example) you didn't consider and the whole thing just collapses in a heap - a nasty to recover heap cause you didn't write much logging code either.

This would REALLY be useful when you're connecting to services external to yourself - network glitches cause more problems with my code than ANYTHING else, and it's a pain in the arse to write code to deal with it gracefully. i'd really really like to see a universal "try this for 5 minutes" wrapper, which, if it still failed, you'd only have one exit condition to worry about. hey, what the hell, maybe i'll spend a few days and write one myself.

One of the few who get it apparently. (4, Informative)

SmallFurryCreature (593017) | more than 10 years ago | (#8567050)

This is indeed little more then the wrapper that you describe. Yet most seem to comment on its non-claimed properties of fixing the programmers errors. Wich it really really doesn't. In fact it is worse since this one would happily keep trying to execute a command like "rm -Rf / home/me/tmp".

I have often had to write such wrappers myself. Sure even easier/better would have been if somebody added this to say BASH as an extension but perhaps that is not possible.

How often have you needed to write horrible bash code just to pull data from an unreliable source and ended up either with a script that worked totally blind "command && command && command &&" wich never reported if it failed for days on end or ended up with several pages just to catch all the damn network errors that could occur.

I will definitly be giving this little language a try in the near future. Just another tool for the smart sys-admin. (smart people write as little code as possible. Let others work for you)

Re:One of the few who get it apparently. (1)

Krach42 (227798) | more than 10 years ago | (#8567283)

Hm... what happens when the first command in your catch says

rm datafile

With no -f? This is a failure condition if the condition is false, thus it would throw the code into an infinite failure loop until the timeout.

Like you're saying though, if it's a programming error, it won't get fixed, and in someways, even worse, it adds new dimensions to think about.

Let's draw a line in the sand... (4, Insightful)

humankind (704050) | more than 10 years ago | (#8566903)


All the programmers who need the environment to compensate for their inadequacies, step on one side. All the programmers who want to learn from their mistakes and become better at their craft, get on the other side.

Most of us know where this line is located.

Re:Let's draw a line in the sand... (4, Funny)

Anonymous Coward | more than 10 years ago | (#8566922)


java, c++, c#

-------------

asm, c ?

Re:Let's draw a line in the sand... (3, Interesting)

Rakshasa Taisab (244699) | more than 10 years ago | (#8567371)

If you think C++ belongs on that side of the line, then you've either never programmed in C++, or you've written some pretty buggy programs (and are ignorant of it). C++ is kinda like a powered chainsaw, effective and powerfull but if you don't know how to use it you'll end up losing a leg or two.

Re:Let's draw a line in the sand... (4, Funny)

LarsWestergren (9033) | more than 10 years ago | (#8566936)

All the programmers who need the environment to compensate for their inadequacies, step on one side. All the programmers who want to learn from their mistakes and become better at their craft, get on the other side.

Most of us know where this line is located.


"In other news, at the local beach today a vicious fight broke out between geeks about where to draw a line. Sand was kicked, noses have been blooded, we have some unconfirmed reports of a wedgie. We will have more on this breaking news as it comes in."

Re:Let's draw a line in the sand... (1)

yess (678141) | more than 10 years ago | (#8567417)

Ok. Wait! One second... Which side is first, which one the second?

Re:Let's draw a line in the sand... (2, Insightful)

Avihson (689950) | more than 10 years ago | (#8566985)

Isn't that line located outside of the unemployment office?

Re:Let's draw a line in the sand... (1)

Androclese (627848) | more than 10 years ago | (#8566998)

Most of us know where this line is located.

yup...

#!/usr/bin/perl -wT
use strict;

Re:Let's draw a line in the sand... (1, Funny)

Anonymous Coward | more than 10 years ago | (#8567187)

I'm with you. Brothers, cast down thy debuggers! Join us in the use of printf()!

Nice, which brings me too.... (5, Interesting)

MrIrwin (761231) | more than 10 years ago | (#8566906)

The idea of being to timeout and exception handle in scripts is a great idea......assuming you want to use scripts. I think most people end up resorting to Perl, Python or whatever for anything more complex. But perhaps with this facility Scripts would be more useful? But...now I come to a related topic. I build factory wide systems, systems which have eg. Automatic warehouses and whatever in the middle. I do a lot of stuff with VB6 not because it is fault tolerant but because it is 'fix tolerant'. During the comminssioning phases I can leave a program running in the debugger and, if it freaks out, I can debug, fix, test by iterating forwards and **backwards** in the the function that caused the hitch, and then continue to run were I left off. Many minor problems get fixed on the fly without users even realizing anything was amiss. In every other respect (syntax, structure, error trapping etc) VB6 is a disaster and not really suited at all to these types of progects, so the fact that I use it is a measure of how important this feature is. Like the fault tolerant shell, it is a 'non-pure' extension insofar as purists say it should not be neccessary, but in pratice it is a godsend. Anybody know an alternative for VB6 in this respect?

Ninja Turtles Have Them (-1, Redundant)

myownkidney (761203) | more than 10 years ago | (#8566909)

Good that attracted attention.

I agree with most of the earlier posters that what is lacking today is good programming techniques. You won't need a fault tolerant shells if you programs are bullet proof. What often happens is these fault tolerant shells become an excuse to write shoddy programs.

Building on their first example (5, Insightful)

gazbo (517111) | more than 10 years ago | (#8566916)

They are deleting a number of files on a number of different machines, then downloading an updated version. The implication is that the fault tolerance means a failure is not fatal.

So what happens if the files are crucial (let's use the toy example of kernel modules being updated): The modules get deleted, then the update fails because the remote host is down. Presumably the shell can't rollback the changes a la DBMS, as that would involve either hooks into the FS or every file util ever written.

Now I think it's a nice idea, but it could easily lead to such sloppy coding; if your shell automatically tries, backs off and cleans up, why would people bother doing it the 'correct' way and downloading the new files before removing the old ones?

Re:Building on their first example (0)

Anonymous Coward | more than 10 years ago | (#8567284)

If you look a bit closer you'll notice that you can add a section of code that runs upon failure, which you could use to clean up.

Re:Building on their first example (1)

gazbo (517111) | more than 10 years ago | (#8567356)

No, you miss my point; I accept that the system has uses, and allows for cleaning up. But look at the code sample on their front page: how exactly do you "clean up" from a `rm -f data`?

The answer is that you don't - you clean up from a `mv data data.tmp`. But with a system that purports to have transaction-like facilities people are going to just assume that the operation is, well, fault tolerant - as evidenced by their own front page code sample!

How long until... (3, Funny)

simon_clarkstone (750637) | more than 10 years ago | (#8566917)

...people start pronouncing "ftsh" as "fetish". Actually, I've started already, just ask the girl sitting next to me. ;-)

Re:How long until... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8566932)

She prolly knows you're gay

creators: fault tolerant, but getting peaced off (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8566957)

consult with/trust in yOUR creators... get ready to brighten up.

login (5, Funny)

Rutje (606635) | more than 10 years ago | (#8566983)

"Password fairly correct. Root login granted."

Re:login (4, Funny)

Linker3000 (626634) | more than 10 years ago | (#8567021)

Yup, imagine 'ole clippy:

Seems you're trying to guess the administrator password. Do you want me to:


* Let you in to save time
* Give you a couple of letters as a clue
* Not let you in until you get it right

Using wget as an example (1)

kasperd (592156) | more than 10 years ago | (#8566989)

It seems like a bad example to me since wget already has a lot of retrying build in.

Re:Using wget as an example (1)

MrIrwin (761231) | more than 10 years ago | (#8567007)

Which brings a 1M$ question.

Should a script always use apps which have built in net problems detection (and return with error), or should we be able to use generic commands which ignore eventual problems and may be potentially hang indefinetly?

IMHO, wget is a good solution if appropriate. But suppose I wanted to e.g. check a file for content based on a remote dictionary, and failing that a local one. This shell could automatically revert to the local copy if the remote (updated) dictionary did not respond in time.

Re:Using wget as an example (1)

kasperd (592156) | more than 10 years ago | (#8567452)

wget is a good solution if appropriate.

With the right options wget is appropriate for almost anything. You'd be surprised to see the list of possible options you can specify for wget. You can specify timeout as well as number of retries, which means it would also be usable for the scenario you describe. Though it seems like wget doesn't have exponential backoff, only linear backoff, and there seems to be no options to change the backoff strategy. Which one of exponential and linear is best of course depends on your point of view.

DOS is pretty fault tolerant... (1)

toesate (652111) | more than 10 years ago | (#8566992)

since it cannot really do a lot (of damage) in the first place!

Anyway, a shell is just a shell is just a shell...

this can essentially already be done in /bin/bash (5, Interesting)

xlurker (253257) | more than 10 years ago | (#8566996)

(the concept of fault-tolerant coding encourages sloppy coding. and it makes it harder to see what's actually happening in the script. but that's not what they actually mean.)

what they seem to essentially want is

  • a try statement and error catching and
  • a fortran like syntax for testing and arithmetic
I think the authors were a bit misguided. Instead of creating a whole new shell how about just extending a good existing shell with a new try statement a described.

it can even be done without extending the shell:

( cd /tmp/blabla
&&
rm -rf tmpdir
&&
wget http://some.thing/wome/where
) || echo something went wrong

as for the new syntax of .eq. .ne. .lt. .gt. .to.
certainly looks like fortran-hugging to me , yuck

as for integer arithmetic, that can be done with by either using backticks or the $[ ] expansion

% echo $[ 12 * 12 + 10 ]
% 154

Golden hammer (2, Insightful)

sangdrax (132295) | more than 10 years ago | (#8567401)

Ofcourse bash can do it as well using the proper constructions. That is not the point. Care should be taken not to view bash as a golden hammer when it comes to shell scripting. The same goes for 'ftsh', ofcourse. It won't try to replace bash for every script out there.

The author merely thinks it would be nice to have a shell in which such fault-tolerant constructions are natural by design. Just to save people headaches when writing simple scripts which are there to get some job done, not to waste time dealing with every single possible failure and time-out by hand.

Once again, Babbage was thinking ahead... (5, Interesting)

andersen (10283) | more than 10 years ago | (#8566997)

"On two occasions I have been asked [by members of Parliament!], 'Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?' I am not able rightly to apprehend the kind of confusion of ideas
that could provoke such a question."
-- Charles Babbage

Why is there a Windows compatible port? (2, Insightful)

OC_Wanderer (729511) | more than 10 years ago | (#8567004)

I'm sorry, but I can't understand why a Windows port (even if not native) is even attempted. Seems kind of useless in a totally GUI environment. Of course, maybe it's just me?

Re:Why is there a Windows compatible port? (2, Insightful)

Anonymous Coward | more than 10 years ago | (#8567046)

Seems kind of useless in a totally GUI environment. Of course, maybe it's just me?

Uh.. it's just you. You should, y'know, maybe try using Windows 2000 or XP sometime... Windows has a perfectly good command line. Point at the "Start" menu, click "Run" -> type "cmd", and away you go.

You can turn on command line completion (search for "TweakUI" or "Windows Powertoys", I can't be bothered to link to them). And even pipes work just fine (as they have since the DOS days). For example:
dir *.txt /s /b > textfiles.txt
type textfiles.txt | more
There's a whole build target type that specifies Win32 executables as command line programs - such programs play nicely with command shells and piped input & output. For example, all the Microsoft compiler tools are command line programs that are wrapped by the GUI. You can pull code from a Visual SourceSafe database and rebuild a project all from the command line if you want - such build mechanisms would be a prime target for a fault tolerant shell (although I think Scons has well solved the rebuild problem itself).

Other tools, such as Python and Perl all play nicely with the command line and could also be used with this shell on Windows.

Re:Why is there a Windows compatible port? (1)

OC_Wanderer (729511) | more than 10 years ago | (#8567111)

I use XP Pro. I run Apache, PHP, and MySQL on it. Still I see no need to this kind of shell.

Re:Why is there a Windows compatible port? (2, Interesting)

Tei (520358) | more than 10 years ago | (#8567331)

Mostly because Windows lack of good command line admin tools historically. Actually has a few, but cmd is not bash, so you have to suplement these..

some people, (I myself too) use bash as a daily basic for Windows, this new stuff can be interesting and maybe usefull for the unsafe windows enviroment.

I don't see why eveyone is complaining... (3, Interesting)

quakeslut (107512) | more than 10 years ago | (#8567006)

What do you lose by using something like this?

Well.. besides pipes of course ;)
Variable redirection looks just like file redirection, except a dash is put in front of the redirector. For example, For example, suppose that we want to capture the output of grep and then run it through sort:

grep needle /tmp/haystack -> needles
sort -< needles

This sort of operation takes the place of a pipeline, which ftsh does not have (yet).

Hi (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8567018)

Me too!

In Monopolistic America (3, Funny)

fruity1983 (561851) | more than 10 years ago | (#8567028)

In monopolistic America, you tolerate faulty shell.

In Soviet Russia... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8567125)

the shell tolerates you!

*pulls out tomato shield*

Fault Tolerance at its best (0, Funny)

Anonymous Coward | more than 10 years ago | (#8567040)

For a scripting language, just follow the VB approach which is already ultra efficient and completely fault-tolerant:

On Error Resume Next

Re:Fault Tolerance at its best (1)

digitalsurgeon (629388) | more than 10 years ago | (#8567114)

yeah rock solid fault tolerance, hehe, it might even "Resume Next" if u show how delete the executable from your file system.

Why don't use screen? (1)

Yag (537766) | more than 10 years ago | (#8567084)

Screen [gnu.org] is a terminal which can survive connection problems. You can start your script, detach terminal, and then came back 10 minutes later and watch what its doing. I know, that's not "fault tolerant", but, most of the times, its enaugh.

A different kind a fault tolerance (0, Offtopic)

de Selby (167520) | more than 10 years ago | (#8567091)

I've always wanted a shell that deletes into a 'garbage' folder, but in a native way so programs calling a delete function would also. I've also wanted a 'file versions' feature to bring safety to accidently overwriting. Then it would really be tolerant of user faults.

While we're at it: a config file library so every config file is the same format; exportable functions so gimp can export gmp.imageResize fileName 800 600 to the shell; and a codecs folder with libraries for image, video, document, and data compression.

Not every might see that last one's benefit, but I think if every app exported its format there (quicktime, realmedia) and let it be universally called, apps would be judged by interface, not filetype support.

Another idea: make every shortcut in X the config file. That way, a simple copy+edit makes two easily created+accessed differently configed programs. (I don't know about network-wide configs, though.)

Re:A different kind a fault tolerance (0)

Anonymous Coward | more than 10 years ago | (#8567273)

I've always wanted a shell that deletes into a 'garbage' folder, but in a native way so programs calling a delete function would also.

Fairly easily done with a preloaded library that intercepts the unlink syscall. Basic idea:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <limits.h>

int unlink(const char *filename)
{
char buf[PATH_MAX];

snprintf(buf, sizeof buf, "%s/%s/%s",
getenv("HOME") ? getenv("HOME") : "/",
[make your new path name here],
filename
);

rename(filename, buf);

return 0;
}
To use: gcc -shared unlink.c -o unlink.so. Then do:

LD_PRELOAD=$PWD/unlink.so rm foobar

This will call the specially crafted unlink() and do whatever it says.

I've omitted a real trash-making algorithm (one that avoids clashes, etc) and I've done no error checking (make sure snprintf() returns a value < (sizeof buf), and that rename() returns 0), but this is just a rough example. Oh yeah, real code wouldn't use rename() because that won't work over different filesystems. But hey, it isn't meant to be used, just as a guide.

A distributed shell ... (2, Interesting)

Anonymous Coward | more than 10 years ago | (#8567095)

... was mentioned a few months back in one of the magazines I pick up almost monthly (forget which one out of the several it was).

I think the shell was called dsh. I believe this is the project site: http://dsh.sourceforge.net/

Are the aims of this fault tolerant shell and dsh the same? I'm not a programmer, but I'm trying to teach myself *nix system administration.

Eventually I'm hoping to cluster some older x86 systems I'm going to get at auction together for a Beowulf cluster. It sounds to me like one if not both of these two shells might come in handy!

OK, wise guys... (5, Interesting)

JAPrufrock (760889) | more than 10 years ago | (#8567120)

I'm working with Grid and ftsh as we speak. I'm a physicist, not a professional coder. I write reasonable code, but I'm no purist. With that said...

ftsh has great utility in the realm it's written for. Obviously, it's not a basis for installing kernels or doing password authentication. In a Grid (not just distributed) environment, things break for all sorts of reasons all the time. You're dealing with a Friendly Admin on another system, one who may well be unaffiliated with your institution, project or field of study. He doesn't have any particular reason to consult with you about system changes.

Now you find yourself writing a grid diagnostic or submitter or job manager. One does not need strongly typed compiled languages for this. Shell scripts are almost always more efficient to write, and the speed difference is unimportant. Right now, most Grid submitters are being written in bash or Python or some such. Bash sucks for exception handling of the sort we're talking about. Python does better with its try: statements, but there's room for improvement. ftsh is a good choice for a sublayer to these scripts. One writes some of the machinery that actually interacts with the Grid nodes and supervisors in this easy, clear and flexible form.

Now there are a lot of specific points to answer:

One needs a Windows port to be able to make the Grid software we write in Linux available to the poor drones who are stuck with Win boxes.

This is not a code spellchecker or coding environment. At all.

This is not a crutch for inadequate programmers. This is a collection of methods to deal with a specific set of recalcitrant problems.

As I was pointing out before, this is, after all, an unstable system. One is using diverse resources on diverse platforms in many countries at many institutions. I appreciate the comment made by unixbob about operating in heterogeneous environments.

This isn't a substitute for wget. One uses wget as an example because it's clear.

The "pull" model breaks down immediately when there is no unified environment, as is described on infrastructures.org. When you're not the admin, and your software has to be wiped out the minute your job is done, "push" is the only way to do it. This is the case with most Grid computing right now (that I know about)

All the woe and doom about the sloppy coding and letting the environment correct your deficiencies is... ill-thought-out. That's what a compiler is, folks. Should we all be coding in machine language? :) Use the right tool for the job and save time.

I do agree, however, that one should indeed hone one's craft. Sloppy coding in projects of importance is inexcusable (M$). There is no reason to stick to strict exception handling, however, in the applications being discussed by ftsh's developers (the same folks who brought you Condor). When code becomes 3/4 exception handling, even when the specific exceptions don't matter, there's a problem, IMHO. :)

rm -rf $(TEMPFILE) /dev/null (1)

Domini (103836) | more than 10 years ago | (#8567122)

This was an obscure typo bug I found this morning (after 3 months)

Argh.

Wish the shell would have added the (obvious) ' > ' :P

"set -e" will go a long way to helping you (4, Interesting)

divec (48748) | more than 10 years ago | (#8567130)

The article says:

#!/bin/sh

cd /work/foo
rm -rf bar
cp -r /fresh/data .

Suppose that the /work filesystem is temporarily unavailable, perhaps due to an NFS failure. The cd command will fail and print a message on the console. The shell will ignore this error result -- it is primarily designed as a user interface tool -- and proceed to execute the rm and cp in the directory it happened to be before.

That shell script can be improved a lot by using " set -e " to exit on failure, as follows:
#!/bin/sh

set -e # exit on failure

cd /work/foo
rm -rf bar
cp -r /fresh/data .


This means that, if any command in the script fails, the script will exit immediately, instead of carrying on blindly.

The script's exit status will be non-zero, indicating failure. If it was called by another script, and that had "set -e", then that too will exit immediately. This is a little bit like exceptions in some other languages.


Re:"set -e" will go a long way to helping you (1)

jaoswald (63789) | more than 10 years ago | (#8567509)

How does this get an "interesting" mod?

Scripts that simply die when they hit an error are not "fault tolerant" or "robust." They are simply par for the course in the UNIX universe, like regular expressions, which work great if everything is just right, and fail terribly when things change.

"Fault tolerant" systems KEEP WORKING in the presence of unexpected events. Emitting an error message and then leaving the user back at the command prompt is exactly the opposite.

This feature is a "little bit" like exceptions in the way that death is a "little bit" like a bump on the head. Real exceptions let you detect errors and then DEAL WITH THEM. They don't just prevent you from deadly accidents.

mod parent up (1)

xlurker (253257) | more than 10 years ago | (#8567510)

excellent comment

this works also:

( cmd1 && cmd2 && cmd3) || echo something went wrong
but "set -e" hits the nail on its head

additionally you could also "set -x" to see where the script exited exactly

I love this... (2, Insightful)

deego (587575) | more than 10 years ago | (#8567160)

.. the shell just got the cool error-handling lisp has always had (condition-case in elisp, for example). From a lisper's perspectice, things will be so much easier now... and I can really try some more scripting..

Been tried (0, Redundant)

old_unicorn (697566) | more than 10 years ago | (#8567191)

Fault tolerant languages, have been tried, and never found to be a food idea. Computer languages are very precise for a reason - What if it reads "der *.*" as "del *.*" not "dir *.*"???

Code not very tolerant of my machine! (2, Informative)

nick_urbanik (534101) | more than 10 years ago | (#8567411)

I finished building the shell after I changed the code that uses a non-standard way of printing the usage message, show_help() in src/ftsh.c. In emacs, I replaced ^\(.*\)\\$ with "\1", and then went back and changed the lines that did not end in a backslash, removed the beginning and ending quotes.

Then it compiled (on Fedora Core 1).

Then it failed the functions test, because my computer does not have the file /etc/networks. For a fault tolerant shell, it does not seem very tolerant of my machine! After sudo touch /etc/networks, make succeeded.

Anyway, those were the only two problems, and now it's installed. Let's see if it's worth building into an RPM package.

If you want a fault tolerant scripting language (4, Informative)

WetCat (558132) | more than 10 years ago | (#8567421)

Erlang (http://www.erlang.org) has it.
You can have multiple linked interpreters and
even fault-tolerant database!
It is a scripting language.
From the FAQ:
1.1. In a nutshell, what is Erlang?
Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson. The most popular implementation of Erlang is available as open source from the open source erlang site.

ACID Filesystems (2, Interesting)

NZheretic (23872) | more than 10 years ago | (#8567458)

For a system like this to be truly effective you would need an operating system which supported a truly transactional filesystem.

Remounting a filesystem with ACID on, a process sets a rollback point , executing a series of commands with the operating system keeping a record of the changes to the filesystem made by the process and its children. The process would inform the OS to either commit or rollback the changes.

This still raises questions on how to deal with with two or more competing "transactional" processes which rely on read information which another process chooses to rollback to an early state.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...