How can I skip to a speific line in a script?

[soldersucker]

How can I skip ahead in the script?

For example : If a $var is greater than or equal to 100 THEN skip to line XX in the script and continue...

IF $var >= 100 THEN...

Now I want to skip ahead to a specific line in the script. How do I do that??? There is no simple command for this.

[Nomad]

How can I skip ahead in the script?

For example : If a $var is greater than or equal to 100 THEN skip to line XX in the script and continue...

IF $var >= 100 THEN...

Now I want to skip ahead to a specific line in the script. How do I do that??? There is no simple command for this.

You just have to learn how to structure your script to accomodate situations like this. There is no way to jump to a specific line in your script, like in some other languages.

Example: The part of the script which would be line 100.. turn it into a function, then you can jump to it when the conditions are met.

Nomad

[soldersucker]

You just have to learn how to structure your script to accomodate situations like this. There is no way to jump to a specific line in your script, like in some other languages.

Example: The part of the script which would be line 100.. turn it into a function, then you can jump to it when the conditions are met.

Nomad

Sure I can structure it. It would just be alot easier if I can "skip to".

Thanks for the fast response!

[Nomad]

Sure I can structure it. It would just be alot easier if I can "skip to".

Thanks for the fast response!

No problem. There are quite a few things which AutoIt could do to make things easier, but they haven't. Maybe in future releases something like this will exist. AutoIt is still evolving after all.

[PsaltyDS]

Sure I can structure it. It would just be alot easier if I can "skip to".

Thanks for the fast response!

I go WAAAAaaaaaaay back with DOS batch files, so I sympathize, but you really will be better off learning to write proper functions. If you've ever read Mr. Wall's Windows NT Shell Scripting, you'll find that simulating proper fuctions (which the DOS shell doesn't really have) using CALL and GOTO :EOF statements is what makes better batch files possible. Using an interpreter that allows real functions makes excellent scripts possible.

It does take some time to get your head around it, but it is well worth the effort. It gets you out of the buggy whip era and closer to where every modern scripting environment and shell interpreter (EXCEPT the DOS command line!) is today.

...and you've found an excellent forum to help you figure it out...

[soldersucker]

Thanks guys. Should be done with the script soon. About 450 lines deep at the moment. My job for the next few months is to setup, configure, and restore backedup data from a server to 1000+ new laptops. My silly IT manager thinks I'm going to be doing it all maunally Its going to be an easy few months.

Edited July 16, 2006 by soldersucker

[MadBoy]

I would suggest to you to use images. If 1000 laptops are exactly the same restoring image is like 5 minutes if you got proper server with gbit nic. Just configure it once. Of course you can always write additional scripts to 'finish' things after restoration. That way 1000 laptops can be done very fast

[soldersucker]

I would suggest to you to use images. If 1000 laptops are exactly the same restoring image is like 5 minutes if you got proper server with gbit nic. Just configure it once. Of course you can always write additional scripts to 'finish' things after restoration. That way 1000 laptops can be done very fast

Not that easy. There are about a dozen different user profiles, programs must be setup with specific user names, VPN must be setup with specific phone #s, user data restoration....etc... etc..

The laptops come to me pre-imaged actually with a basic universal corp. image.

[nitekram]

No problem. There are quite a few things which AutoIt could do to make things easier, but they haven't. Maybe in future releases something like this will exist. AutoIt is still evolving after all.

If I am not wrong - I believe in version 2, the goto function was available. But with the ablility to call a function, why would you need it?

[Nomad]

If I am not wrong - I believe in version 2, the goto function was available. But with the ablility to call a function, why would you need it?

There are some situations in which the ability to jump ahead in a function, and to jump back, would be preferable to creating an entirely new function, or functions.

A good example (just hypothetical) would be to look at the structure for assembly. Could you imagine how many functions you would need to create if you converted the average assembly program to AutoIt? Not to mention the significantly increased size of the script.

I'm sure a number of people can argue that this concept is not needed, while others can argue that it is needed. But if there is just one possible need for the function, then why not have it? There are some other functions which AutoIt has that are less useful, but they are still there. For example, the Call() function. Why do you need it? You don't have to use it to call a function, and it doesn't do anything that's not done by simply calling the function like: "Function()", so why have it? I can't think of a single reason to have it. If somebody can give me just one good reason to have it, I'll accept that's it's not completely useless.

Nomad

[nitekram]

There are some situations in which the ability to jump ahead in a function, and to jump back, would be preferable to creating an entirely new function, or functions.

A good example (just hypothetical) would be to look at the structure for assembly. Could you imagine how many functions you would need to create if you converted the average assembly program to AutoIt? Not to mention the significantly increased size of the script.

I'm sure a number of people can argue that this concept is not needed, while others can argue that it is needed. But if there is just one possible need for the function, then why not have it? There are some other functions which AutoIt has that are less useful, but they are still there. For example, the Call() function. Why do you need it? You don't have to use it to call a function, and it doesn't do anything that's not done by simply calling the function like: "Function()", so why have it? I can't think of a single reason to have it. If somebody can give me just one good reason to have it, I'll accept that's it's not completely useless.

Nomad

Would it be better to be able to have a function in a function? I have no oppion either way - just trying to learn.

[Nomad]

Would it be better to be able to have a function in a function? I have no oppion either way - just trying to learn.

I don't think I've ever seen that done. I don't see how it would be any different than having the function outside of the function, you'd still have to call it and the program would have to jump to it. Unless it could possibly reduce the time of the jump because the function would be within the function. But as for the time involved, this would really only be a factor in large programs, and the same is true of the Goto function.

As far as trying to learn, this is all hypothetical anyway, so you're only learning theory. Unless you have plans to write your own language.

Either way, I can live without the Goto function. I haven't made any scripts with AutoIt yet where I was wishing I had it. I just think it has it's uses, in theory.

[Valik]

There are some situations in which the ability to jump ahead in a function, and to jump back, would be preferable to creating an entirely new function, or functions.

In a procedural language like AutoIt, there is not.

A good example (just hypothetical) would be to look at the structure for assembly. Could you imagine how many functions you would need to create if you converted the average assembly program to AutoIt? Not to mention the significantly increased size of the script.

That is a terrible example. Based on your logic, goto would be used all over the place in porting a program written in assembly to C/C++. However, chances are the program started out in C\C++ without a single goto statement in the first place. The only "valid" use I've ever since for goto in C\C++ is to get out of deeply nested loops without having to create a large number of flags to signal when to exit each loop (I personally would create the flags). In AutoIt, it's possible to use ExitLoop to leave multiple loops from a single location so even using goto to get out of nested loops is unnecessary.

I'm sure a number of people can argue that this concept is not needed, while others can argue that it is needed. But if there is just one possible need for the function, then why not have it?

Because it's not needed, despite what poor designers think.

There are some other functions which AutoIt has that are less useful, but they are still there. For example, the Call() function. Why do you need it? You don't have to use it to call a function, and it doesn't do anything that's not done by simply calling the function like: "Function()", so why have it? I can't think of a single reason to have it. If somebody can give me just one good reason to have it, I'll accept that's it's not completely useless.

Nomad

Simple, it allows AutoIt scripts to implement callback functionality. This is helpful for people writing generic libraries. Imagine a file search algorithm that used callback functions to manipulate the files instead of having to have 4 different copies of the same algorithm around each with a hard-coded action.

Also, comparing Call() to goto is another bad example. The functionality that Call() provides can not be achieved in any other way because of the syntax rules of the language. The functionality goto provides can be emulated in a poor-man's way (Create a single local "jump" is possible by using a dummy loop and ExitLoop). Better yet, it can be avoided by writing good code.

[Nomad]

I assume it was your idea to have it removed in the first place? If it was such a bad idea and sooooo not needed in a procedural language like AutoIt, then why was it ever in there in the first place?

I'll make a sample 100 line assembly program. You can port it anyway you want (without using goto since you say it's not needed), and I'll port it without using more than 1 function. We'll see who's script is dramatically shorter, and if AutoIt could execute the asm, the shorter script would also be faster.

[ending]

I agree with Valik on removing it.

If its not needed, then why leave it to allow people to develop bad habits?

[Valik]

I assume it was your idea to have it removed in the first place?

It was never removed because it was never in AutoIt 3.

If it was such a bad idea and sooooo not needed in a procedural language like AutoIt, then why was it ever in there in the first place?

It was in AutoIt v2. I wouldn't call v2 a procedural language. I'd call it a mess but that's mostly because I hated the syntax.

I'll make a sample 100 line assembly program. You can port it anyway you want (without using goto since you say it's not needed), and I'll port it without using more than 1 function. We'll see who's script is dramatically shorter, and if AutoIt could execute the asm, the shorter script would also be faster.

If you sincerely think that porting from assembly to a high-level language is going to even remotely look like the source, you need to go to the store and buy the game of "Clue" because it's the only way you'll ever get one. I'm not interested in replicating assembly in a high-level language. I would look at what the assembly program does and then port it's functionality to another language. I wouldn't try to emulate every single line using the closet language construct in the target language.

Edit: Fixed typo.

Edited July 17, 2006 by Valik

[Nomad]

I would look at what the assembly program does and then port it's functionality to another language. I wouldn't try to emulate every single line using the closet language construct in the target language.

If you tried to port the functionality of an assembly program without using Goto (a jump), you would have a coding nightmare. You'd need a separate function for almost every line of code. Basically every time you encountered a jump, or a conditional jump, you'd have to make a new function. Otherwise you wouldn't be able to jump back to where you left off if the need arised 300 jumps later, or you'd have a recursive mess.

Yeah, you don't need Goto for the common variety everyday script. But it has it's uses. AutoIt is not the last word in programming, this is proved by the need for the DllCall. Even with that, AutoIt is still not capable of performing every situation that can be thought up. So why limit it further by removing functionality?

[Valik]

If you tried to port the functionality of an assembly program without using Goto (a jump), you would have a coding nightmare. You'd need a separate function for almost every line of code. Basically every time you encountered a jump, or a conditional jump, you'd have to make a new function. Otherwise you wouldn't be able to jump back to where you left off if the need arised 300 jumps later, or you'd have a recursive mess.

This is absolute stupidity. There's a significant chance that the original code for any given (dis)assembly program was not written using a single goto so this logic is just stupid.

Yeah, you don't need Goto for the common variety everyday script.

You don't need it at all. Once you stop insisting that you do, you'll be a better programmer.

But it has it's uses. AutoIt is not the last word in programming, this is proved by the need for the DllCall.

It does not have it's uses in AutoIt. It has it's uses in language where this is no other way to do things. AutoIt is not that language. Your comments about DllCall() are unrelated.

Even with that, AutoIt is still not capable of performing every situation that can be thought up.

I would guarantee that I can do more with AutoIt than you can even fathom. So can a lot of people. The fact that you were unable to find a legitimate use for something as simple as Call() proves to me that you can't think outside of a specific box you are currently in.

So why limit it further by removing functionality?

Again, goto was never removed. It was consciously left out of AutoIt 3 from the beginning. Have you looked at AutoIt 2? It's a completely different style of language. Version 3 has never had goto removed because it was never in version 3.

[Nomad]

This is absolute stupidity. There's a significant chance that the original code for any given (dis)assembly program was not written using a single goto so this logic is just stupid.

And why do you think it was converted to assembly? Because it's going to run faster that way...

You don't need it at all. Once you stop insisting that you do, you'll be a better programmer.

I never insisted anything. I said it has it's uses. In fact, I said I didn't really care if it was in there or not, do some more reading.

It does not have it's uses in AutoIt. It has it's uses in language where this is no other way to do things. AutoIt is not that language. Your comments about DllCall() are unrelated.

Well, AutoIt is written in C++, correct? And in C++ there is a Goto command, and C++ also has the ability to create functions just like AutoIt does. So I guess the creator of C++ is just a dumbass, right? Then why was his language used to create this one?

I would guarantee that I can do more with AutoIt than you can even fathom. So can a lot of people. The fact that you were unable to find a legitimate use for something as simple as Call() proves to me that you can't think outside of a specific box you are currently in.

I would hope you know more about AutoIt than me, you're one of the developers after all. But you might be surprised what I can "Fathom". I've already "Fathomed" concepts that AutoIt is not even capable of performing. So why don't you show me that you can create "more than I can fathom", as you stated you could just now. Here's the link, show me your stuff:

My Fathoms

Start by looking at post #61 and #62. I've done this in C++ and the looptime is under 2 minutes. With AutoIt it's over 4 hours. I'd like to see it duplicated. let me know if you need some more info.

Again, goto was never removed. It was consciously left out of AutoIt 3 from the beginning. Have you looked at AutoIt 2? It's a completely different style of language. Version 3 has never had goto removed because it was never in version 3.

Nope, I never laid eyes on AutoIt v2.

Nomad

[Valik]

And why do you think it was converted to assembly? Because it's going to run faster that way...

If we are talking about a C++ program, it's not about running faster, it's about running, period. The CPU does not uderstand C++, it understands machine code which is easily translatable to assembly. Speed really has nothing to do with it.

I never insisted anything. I said it has it's uses. In fact, I said I didn't really care if it was in there or not, do some more reading.

I read that. But you still insist it has uses. I say that it does not, at least it does not have valid uses.

Well, AutoIt is written in C++, correct? And in C++ there is a Goto command, and C++ also has the ability to create functions just like AutoIt does. So I guess the creator of C++ is just a dumbass, right? Then why was his language used to create this one?

C++ has goto because C++ is a superset of C which had goto. I'm sure goto seemed like a good idea to add to C thirty years ago.

I would hope you know more about AutoIt than me, you're one of the developers after all. But you might be surprised what I can "Fathom". I've already "Fathomed" concepts that AutoIt is not even capable of performing.

Just because you can't doesn't mean AutoIt can't.

So why don't you show me that you can create "more than I can fathom", as you stated you could just now. Here's the link, show me your stuff:

My Fathoms

Start by looking at post #61 and #62. I've done this in C++ and the looptime is under 2 minutes. With AutoIt it's over 4 hours. I'd like to see it duplicated. let me know if you need some more info.

Nope, I never laid eyes on AutoIt v2.

Nomad

I'm not interested in doing your work. I have enough work of my own to do. However, I read your post. Scan the memory the application is using, not everything in the entire 2GB virtual address space. Learn which pages you actually need to scan and scan those. You'll never get the performance down to C++ speed but you can bring it down some by writing a smarter scan algorithm.