Jump to content

Recommended Posts

objInputFile.Close
objOutputFile.Close

I know that ;) What I don't know is whether these lines may have any impact when the script is used like I do it.

In a perfect world, where things always work the way they are supposed to, no I don't think so. But as Den explained, just because those files are "supposed" to be closed automatically when the script exits, there is no guarantee that they will, due to system error or whatever. I know that there is never a guarantee with computers anyway, but to decrease the possibility of error with very minimal effort on your part, it is always best practice to clean up after yourself and do what you can to ensure that files are closed and system resources are released when you no longer need them.

Cheers and Regards

Link to comment
Share on other sites


objInputFile.Close
objOutputFile.Close

I know that ;) What I don't know is whether these lines may have any impact when the script is used like I do it.

In a perfect world, where things always work the way they are supposed to, no I don't think so. But as Den explained, just because those files are "supposed" to be closed automatically when the script exits, there is no guarantee that they will, due to system error or whatever. I know that there is never a guarantee with computers anyway, but to decrease the possibility of error with very minimal effort on your part, it is always best practice to clean up after yourself and do what you can to ensure that files are closed and system resources are released when you no longer need them.

I couldn't put it any better if I tried. And this is something that holds true for any generalized OS, which usually are articulated around the files & resources metaphor(s) (except, maybe, for those few that are explicitly built around strongly-enforced "garbage-collection").

Link to comment
Share on other sites

It goes back to the distinction between "general purpose" and "specialized". A general purpose function that might end up being used anywhere needs all kinds of error checking for safety for the app and the system it is run on. The more specialized the function is, the more conditions are assumed or required and the smaller the code can be, as long as it can be guaranteed that those conditions are always met. The error checking always needs to be done, explicitly by the function or implicitly by the programmer. Either in the function itself, or external to it as jaclaz stated:

(which should be made BEFORE in the calling batch)

And then it gets down to programmer's preference. Some like to have redundant checks everywhere, trying to make their code absolutely bulletproof. It will never happen, human error, machine error, and fate will prevent it, but you can get close. Others like to program lean and mean with the absolute minimal checks. That produces smaller, faster code, not as big a requirement these days with processor speed and memory and disc sizes and prices being what they are, but in a perfect world it will run very well. Or you could do a middle ground of the minimal checks plus some extra ones "just in case". If the extra checks are just a line or two and don't take a lot of time to execute, then put them in. You can always pull them back out later as you are optimizing your code and you see which conditions are most likely to occur. That is what you are doing now, and you are doing it the right way, carefully. :)

-::End of philosophical programming methodology rant::-

Cheers and Regards

Link to comment
Share on other sites

Some like to have redundant checks everywhere, trying to make their code absolutely bulletproof. It will never happen, human error, machine error, and fate will prevent it, but you can get close.

I call that foolproof instead. :ph34r:

And of course:

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

;)

Usually it is a no-win/no-win situation, what you get at the end is more complex code/script, and anyway someone will be able to have it break or do something else. :(

I believe more in making the bare minimum checks and make the final user break it at will until he/she learns how to use it properly, i.e. make him/her more responsible, or if you prefer to behave more proactively than the usual "passive mode", expecially since batches/little .vbs scripts are normally a QUICK workaround around an issue or a more convenient way to run a set of otherwise complex commands.

The fact that I know not any other programming language and the usual guy which comes out saying "it can't be done in batch" sometimes causes the creation of one of my senselessly complex :w00t: batches (that a real programmer would write in a much more suitable language), but they still remain "quick and dirty tools" or (working ;) ) POC's, I would say that a suitable adjective for batches (and to a lesser extent .vbs) is "legacy":

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/legacy-is-not-a-pejorative.html

legacy (adj) — A pejorative term used in the computer industry meaning "it works"

Now, the essence of a "quick and dirty" tool is to be BOTH quick AND dirty..... :whistle:

jaclaz

Link to comment
Share on other sites

  • 2 weeks later...

IMHO this is - besides smaller - "plainer":

1.000 bytes instead of 1.356 BUT including 10 bytes for the "@ECHO OFF", so actually 366 bytes smaller or almost 27% smaller :w00t:;).

@ECHO OFF&(
ECHO ^If WScript.Arguments.Count ^<^> 2 then
ECHO WScript.Quit
ECHO end ^If
ECHO Const ForReading=1, ForWriting=2
ECHO Dim i,j
ECHO Set objFSO=CreateObject^("Scripting.FileSystemObject"^)
ECHO Set objInputFile=objFSO.OpenTextFile^(WScript.Arguments.Item^(0^),ForReading^)
ECHO Set objOutputFile=objFSO.OpenTextFile ^(WorkingDir ^& WScript.Arguments.Item^(1^),ForWriting,True^)
ECHO Set objDict=CreateObject^("Scripting.Dictionary"^)
ECHO objDict.CompareMode=1
ECHO j=0
ECHO On Error Resume Next
ECHO While Not objInputFile.AtEndOfStream
ECHO arrinputRecord=split^(objInputFile.Readline,"vbNewLine"^)
ECHO strFirstField=arrinputRecord^(0^)
ECHO ^If objDict.Exists^(strFirstField^) then
ECHO j=j+1
ECHO Else
ECHO objDict.add strFirstField,strFirstField
ECHO End ^If
ECHO Wend
ECHO colKeys=objDict.Keys
ECHO For Each strKey in colKeys
ECHO objOutputFile.writeline objDict.Item^(strKey^)
ECHO Next
ECHO objInputFile.Close
ECHO objOutputFile.Close
)>yanklines.vbs

jaclaz

How about this one :angel

SET tokens=1
:yanks
FOR /F "tokens=%tokens% delims=;" %%A IN ("If WScript.Arguments.Count <> 2 then;WScript.Quit;end If;Const ForReading=1, ForWriting=2;Dim i,j;Set objFSO=CreateObject("Scripting.FileSystemObject");Set objInputFile=objFSO.OpenTextFile(WScript.Arguments.Item(0),ForReading);Set objOutputFile=objFSO.OpenTextFile (WorkingDir & WScript.Arguments.Item(1),ForWriting,True);Set objDict=CreateObject("Scripting.Dictionary");objDict.CompareMode=1;j=0;On Error Resume Next;While Not objInputFile.AtEndOfStream;arrinputRecord=split(objInputFile.Readline,"vbNewLine");strFirstField=arrinputRecord(0);If objDict.Exists(strFirstField) then;j=j+1;Else;objDict.add strFirstField,strFirstField;End If;Wend;colKeys=objDict.Keys;For Each strKey in colKeys;objOutputFile.writeline objDict.Item(strKey);Next;objInputFile.Close;objOutputFile.Close") DO IF NOT "%%A"=="" (ECHO>>yanklines.vbs %%A& SET /a tokens+=1& GOTO :yanks)

It's smaller (924 bytes vs. 998 bytes) and you also don't need to use any carets. The lines are merged into one and separated using semicolons.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...