Page 1 of 1

Pros and Cons of starting a script "setlocal"

Posted: 30 Jun 2010 15:12
by alan_b
I notice many solutions here commence with the line
@echo off &setlocal

In the past I have only ever used setlocal for the benefit of delayed expansion,
and normally I try to avoid delayed expansion where possible and never consider a setlocal.

I can see an advantage that any new environment variables will be purged from memory when the script ends, but I guess that ONLY applies if CMD.EXE is launched once and then a succession of batch commands are manually invoked - but how significant is that space now the cheapest computers have 1 or more GB of RAM, and we are no longer subject to Bill Gates original decree that 640 KB was more than enough RAM for anybody.

Are there any other benefits to always starting with SETLOCAL ?

One disadvantage that occurs to me is that when I write I script I always test it,
and then I need to fix it.
Often when the script gives the wrong answer, I find the clue with
SET
which shows all the variables, and what I did wrong to the new variables,
and that debug aid will vanish if my new variables evaporate upon an (implied) endlocal.

Regards
Alan

P.S. With only myself + 4 guests logged in, this site is incredibly slow.
Is it under another spammer/hacker attack ?

Re: Pros and Cons of starting a script "setlocal"

Posted: 30 Jun 2010 15:49
by aGerman
Hello Alan.

The SETLOCAL command is absolutely useless if you would always run the batch file by double clicking it.
I have often opened a command prompt for testing command lines or batch files. If you would drag'n'drop several batch files to this command prompt they run into the same parent cmd process. Unintended effects are the result if you would use the same variable names into different batch files. Previously set values are available ...

Finaly, @echo off &setlocal is one of my defaults. It may not help but won't do any harm either (mostly :wink: ).

Regards
aGerman

Re: Pros and Cons of starting a script "setlocal"

Posted: 01 Jul 2010 09:12
by alan_b
Thank you for the explanation.
You have now convinced me to adopt your style unless I need to see the "SET" variables as a result of running a script.

I like your phrase "Unintended effects are the result",
but my absolute all-time favourite has to be
"The results are undefined".

When I was part of a larger group made redundant the Unemployment agency funded a 'C' training course.
We were taught 'C' on multi user terminals supported by one small "mainframe".
We used the Unix "VI" editor, and each of us had to wait in a queue for our code to be compiled.

20 years later I still remember the terrible clatter as the Line Printer burst into life with a massive "Core Dump",
and like little children in nursery we all had to chant together with the tutor
"The results are undefined"
and then she would look at the code at tell us what silly syntax error had broken the computer !

Happy days ! !
Alan

Re: Pros and Cons of starting a script "setlocal"

Posted: 01 Jul 2010 10:35
by aGerman
Alan

I fell on the floor laughing when I read your post - thanks for the story.

ymmd :D
aGerman

Re: Pros and Cons of starting a script "setlocal"

Posted: 02 Jul 2010 11:34
by avery_larry
When I have script files that call other script files, I will sometimes use setlocal and endlocal to make sure I don't accidentally use the same variable name in both scripts, and subsequently mess up the calling scripts variable values. Since I'm doing the coding, it's fairly likely that I'll use similar/same variable names.

Re: Pros and Cons of starting a script "setlocal"

Posted: 08 Jul 2010 13:55
by alan_b
None of my scripts move from D:\ and onto C:\ until I have finished testing/adjusting.

When a script explores / evaluates the contents of C:\,
I have been resigned to the need to re-establish D:\ as the current drive before I re-run.

I have just realised I do not have to do that any more now the script starts
@echo off &setlocal

In theory it is now obvious - I just had not thought about it before.

On the few occasions when I need a clue on why a script does what it didn't oughta,
I just rerun the script after I append
SET

Regards
Alan