[jaclaz]

bphlpt, on 19 September 2012 - 03:18 PM, said:

I believe (1) is very necessary, or or least the "< 2" part is, since I'm not sure what will happen, besides error, if you do not specify both the input and output file. If you have extra arguments, ie "> 2", they will just be ignored but it is an indication that something is screwed up in the program call.

I don't get it.
That would be a check to make sure that exactly 2 arguments are passed to the script, if the script is invoked only from a batch and only with the correct 2 arguments there is no need for that check (which should be made BEFORE in the calling batch).
Or am I missing something?

jaclaz

[tomasz86]

dencorso, on 19 September 2012 - 09:02 PM, said:

Removing these lines you'd be introducing a potential bug by relying on behavior which is not guaranteed.
And running a large number of times such a buggy script may lead to all kinds of hard to debug conditions.
Don't ever forget to close all open files before terminating.

What do you mean by "closing" files?

This is how I use the script:

(
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
)>TEMP\yanklines.vbs
FOR /F "tokens=* delims=" %%I IN ('DIR/B/S "%SPLITDIR%"') DO (
	START "yanklines" /WAIT TEMP\yanklines.vbs "%%I" "TEMP\temp.txt"
	MOVE "TEMP\temp.txt" "%%I"
)

[bphlpt]

jaclaz, on 20 September 2012 - 02:45 AM, said:

bphlpt, on 19 September 2012 - 03:18 PM, said:

I believe (1) is very necessary, or or least the "< 2" part is, since I'm not sure what will happen, besides error, if you do not specify both the input and output file. If you have extra arguments, ie "> 2", they will just be ignored but it is an indication that something is screwed up in the program call.

I don't get it.
That would be a check to make sure that exactly 2 arguments are passed to the script, if the script is invoked only from a batch and only with the correct 2 arguments there is no need for that check (which should be made BEFORE in the calling batch).
Or am I missing something?

jaclaz

You are absolutely correct, of course, as long as the assumption is assured. I think both Den and I were looking at the code snippet from a "stand-alone" perspective, or as a function you might paste into another piece of code or share with someone else. No comment was made in the last few posts as to any assumptions or requirements, either before or after yanklines.vbs is invoked, so not knowing if the proper error checking had been done before the function was called ...

tomasz86, on 20 September 2012 - 05:09 AM, said:

dencorso, on 19 September 2012 - 09:02 PM, said:

Removing these lines you'd be introducing a potential bug by relying on behavior which is not guaranteed.
And running a large number of times such a buggy script may lead to all kinds of hard to debug conditions.
Don't ever forget to close all open files before terminating.

What do you mean by "closing" files?

He's talking about

objInputFile.Close
objOutputFile.Close

Cheers and Regards

This post has been edited by bphlpt: 20 September 2012 - 10:28 AM

[tomasz86]

bphlpt, on 20 September 2012 - 10:24 AM, said:

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.

[jaclaz]

Slightly bigger but allows to copy and paste the script "as is" (without any need for carets) at the END of the batch....

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS

FOR /F "tokens=1 delims=[]" %%A in ('FIND /N "::THIS IS START OF VBS SCRIPT::" %~dpnx0') DO SET More_offset=%%A
ECHO 'Hi I am yanklines.vbs script>yanklines.vbs
FOR /F "tokens=*" %%A IN ('MORE +%More_offset% %~dpnx0') DO ECHO %%A>>yanklines.vbs
ECHO do whatever the batch is supposed to do
GOTO :EOF

::THIS IS START OF VBS SCRIPT::
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

jaclaz

[bphlpt]

tomasz86, on 20 September 2012 - 11:51 AM, said:

bphlpt, on 20 September 2012 - 10:24 AM, said:

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

[dencorso]

bphlpt, on 20 September 2012 - 12:44 PM, said:

tomasz86, on 20 September 2012 - 11:51 AM, said:

bphlpt, on 20 September 2012 - 10:24 AM, said:

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").

[tomasz86]

Understood

But the first three lines are not required when both source and destination is always specified as in my script, right?

If WScript.Arguments.Count <> 2 then
WScript.Quit
end If

[dencorso]

Yes. Any conditional that is either always true or never true is not needed.

[bphlpt]

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:

Quote

(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

[jaclaz]

bphlpt, on 21 September 2012 - 12:46 AM, said:

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.

And of course:

Dougals Adams said:

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 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.ntlw...pejorative.html

Quote

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.....


jaclaz

[tomasz86]

jaclaz, on 19 September 2012 - 12:28 PM, said:

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 .

Spoiler

@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

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.

[jaclaz]

tomasz86, on 06 October 2012 - 02:47 AM, said:

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.

And also completely unreadable.

jaclaz