[ArkPhaze]

A goto is not quite the same as calling exit directly; there's no jump, you are skipping the jump and doing exactly what you intended to do after the jump. And actually it's probably better that you either use exit or goto :eof (you don't need :eof block anywhere). Because if you decide to add some functions later on, usually people end up putting them at the end of the script, and if you put it right after :end, thinking that when you goto :end, you are going to eof, things will run unintentionally. It's good practice to avoid having to deal with these possibilities.

I actually start with something that looks like this before I start writing anything else in a batch script:

Code:

@echo off

pause & goto :eof

This is so that I can easily double click test the file without having to type it in and invoke it myself. But the goto :eof is there so that I can add functions at the end of my script without worrying about any unwanted adverse effects it may cause to the rest of my script.

If you are running this script as admin then that's something I didn't consider.

And the reason for avoiding common command names and variable names in scripts as other identifiers is because I've seen lots of people forget !! or %%. If you have a bit of bytes of work into the script you are working on, this is sometimes not easy to debug. Batch is not something like C# or C++ where you can use breakpoints, tracepoints, and step through your code unless you enjoy echo'ing things and placing pause's everywhere.

Yeah, I know that, but it's nowhere an issue.

Perhaps now, but you're assuming things. And if you decided to use assoc later on, you'll have to remember to be careful because of the fact that you decided to name a block with the same text.

Variable naming is important, just because batch is a measly programming language doesn't mean it's not important for batch either. It just becomes more strict when you get into languages like C#, C/C++, etc...

Well, but there may be even no args or 1, 2, 3, 4, 5 or 6 valid arguments. If you meant that I could check first for the number of args and then not check for those args (like in the code two quotes beneath), well, I think it's kinda pointless.

That doesn't mean that you can't invoke the help menu when there are no args. Then the initial condition might be something like if %arg_count% == 0 or the first argument (%1) == "-help" show the help menu. If this doesn't run true, then we know that the first argument has a value at least because the argument count is not 0, and the first argument is not "-help" either, so we can check to see what %1 is, to give us an indication on what the user might be trying to do. And use that to decide an expected number of filled arguments, that we can check thereafter.

It doesn't matter to check 3, 4, 5, or 6 for instance of arg %1 hasn't been filled yet because it goes in order.

I mean for each branch that you have, based on which arguments are inputed, it would be more efficient to first check if the # of args is correct for what the user is trying to do, before you start validating arg %1, then %2, and then go to validate arg %3 when it doesn't even exist. Checking that there are 3 args first will save you the time, and is a better method of avoiding issues as well. Validate after you know that all of the args are there. If arg %1 dictates what the user is trying to do, then check it, to see what the script would do, count and compare the expected # of args, and use that for a first wall of validation.

Without getting into too much detail, all I'm saying is that you don't really have much validation on user input.

Batch is an easy language, but unless you format kind of like Python with indentation, there is none, there is no way to see where things start and end, without taking the time to look through the code. So this makes batch frustrating if you don't write code to make things easier for you in the future writing sessions for the same script. That's what I'm mentioning all of these things that truly depend on all of the "if"s. Because as a developer, I've been on many projects where I think I will never implement something, and coincidentally find myself adding it in later, and my code before was not prepared for the addition, causing me troubles in the future.

Write your code with no assumptions, it's one of the best practices you can get into.

EDIT: Good example of what I'm talking about:

Code:

@echo off
call assoc
pause
goto :eof
:assoc
echo HI

And because I forgot to write one ":".

[ArkPhaze]

A goto is not quite the same as calling exit directly; there's no jump, you are skipping the jump and doing exactly what you intended to do after the jump. And actually it's probably better that you either use exit or goto :eof (you don't need :eof block anywhere). Because if you decide to add some functions later on, usually people end up putting them at the end of the script, and if you put it right after :end, thinking that when you goto :end, you are going to eof, things will run unintentionally. It's good practice to avoid having to deal with these possibilities.

I actually start with something that looks like this before I start writing anything else in a batch script:

Code:

@echo off

pause & goto :eof

This is so that I can easily double click test the file without having to type it in and invoke it myself. But the goto :eof is there so that I can add functions at the end of my script without worrying about any unwanted adverse effects it may cause to the rest of my script.

If you are running this script as admin then that's something I didn't consider.

And the reason for avoiding common command names and variable names in scripts as other identifiers is because I've seen lots of people forget !! or %%. If you have a bit of bytes of work into the script you are working on, this is sometimes not easy to debug. Batch is not something like C# or C++ where you can use breakpoints, tracepoints, and step through your code unless you enjoy echo'ing things and placing pause's everywhere.

Yeah, I know that, but it's nowhere an issue.

Perhaps now, but you're assuming things. And if you decided to use assoc later on, you'll have to remember to be careful because of the fact that you decided to name a block with the same text.

Variable naming is important, just because batch is a measly programming language doesn't mean it's not important for batch either. It just becomes more strict when you get into languages like C#, C/C++, etc...

Well, but there may be even no args or 1, 2, 3, 4, 5 or 6 valid arguments. If you meant that I could check first for the number of args and then not check for those args (like in the code two quotes beneath), well, I think it's kinda pointless.

That doesn't mean that you can't invoke the help menu when there are no args. Then the initial condition might be something like if %arg_count% == 0 or the first argument (%1) == "-help" show the help menu. If this doesn't run true, then we know that the first argument has a value at least because the argument count is not 0, and the first argument is not "-help" either, so we can check to see what %1 is, to give us an indication on what the user might be trying to do. And use that to decide an expected number of filled arguments, that we can check thereafter.

It doesn't matter to check 3, 4, 5, or 6 for instance of arg %1 hasn't been filled yet because it goes in order.

I mean for each branch that you have, based on which arguments are inputed, it would be more efficient to first check if the # of args is correct for what the user is trying to do, before you start validating arg %1, then %2, and then go to validate arg %3 when it doesn't even exist. Checking that there are 3 args first will save you the time, and is a better method of avoiding issues as well. Validate after you know that all of the args are there. If arg %1 dictates what the user is trying to do, then check it, to see what the script would do, count and compare the expected # of args, and use that for a first wall of validation.

Without getting into too much detail, all I'm saying is that you don't really have much validation on user input.

Batch is an easy language, but unless you format kind of like Python with indentation, there is none, there is no way to see where things start and end, without taking the time to look through the code. So this makes batch frustrating if you don't write code to make things easier for you in the future writing sessions for the same script. That's what I'm mentioning all of these things that truly depend on all of the "if"s. Because as a developer, I've been on many projects where I think I will never implement something, and coincidentally find myself adding it in later, and my code before was not prepared for the addition, causing me troubles in the future.

Write your code with no assumptions, it's one of the best practices you can get into.

EDIT: Good example of what I'm talking about:

Code:

@echo off
call assoc
pause
goto :eof
:assoc
echo HI

And because I forgot to write one ":".

[noize]

Update: version 2.1 out now.

Not great improvements in the code but a few corrections. The brief change log is in the original post.

[ArkPhaze]

Keep up the good work.

[SlamberGamer]

this is bat format right? ................

[noize]

this is bat format right? ................

*.bat or *.cmd, yes, both work fine.

[TrojanzBoy]

Looks great. Didn't try it yet, though. But I will later.

[TrojanzBoy]

Looks great. Didn't try it yet, though. But I will later.

[postman65]

just a quick question,would the spoofer work on cable modems

[noize]

just a quick question,would the spoofer work on cable modems

Huh?

It's got nothing to do with your modem (yes, it will).