I have two EXE files , one for encryption and other for decryption.
Now i want to call these exe's in my ASP pages built in VB script to encrypt these values and save then in a file.
These exe's take two or three values as parameters and return two values in XML form.
for exapmle :
Calling exe :: c:\IKish\Shared\Encrypt>Encrypt.exe /iv:"xx xx xx" /text:user
Output ::
<Evalue>
<key>784cjidbdk77fkdl161c</key>
<Result>9kflo53jvo1ce4801kskbf399b7</Result>
</Evalue>
Could someone pls help me with the code to execute the exe and catch its output in the ASP file?
Set oShell = Server.CreateObject("WScript.Shell")
Set oExec = oShell.Exec("Encrypt.exe /iv:""xx xx xx"" /text:user")
If Not (oExec Is Nothing) Then
strOutput = oExec.StdOut.ReadAll
End If
Related
I am working on an ASP classic website, which the client reported suddenly exhibited an issue with a previously working function which listed only "image" file types. Upon reading the code, I found that the loop that lists the files in a folder, uses the InStr() function to identify files by their type, which should be "image." However, I found that something must have changed in the OS, as the type is not longer "image", but "JPG", or "PNG", etc. This dramatically changes the way the code works. Following is a snipped of the code:
Set oFSO = Server.CreateObject("Scripting.FileSystemObject")
Set oFolder = oFSO.GetFolder(Server.MapPath(sCurrentDirectoryPath))
Set oSubFolder = oFolder.Files
iFileCount = 0
For Each oFileName in oSubFolder
If InStr(1, LCase(oFileName.Type),"image") > 0 Then
iFileCount = iFileCount + 1
End If
Next
Because the InStr() function is trying to find a file type of "image", no files are counted up, and the function returns zero files found. Whilst debugging, I found that the value being returned by oFileName.Type, was as follows:
This is the file type:JPG File
This is the file type:JPG File
This is the file type:Text Document
This is the file type:Data Base File
Files in the folder were two "whatever.jpg" files, a "whatever.txt" file, and a "thumbs.db" file. So, it appears that the OS (Windows Server 2019) may have changed to be less generic with reporting an "image" file, and is now reporting "JPG file" or "PNG file", etc. This of course, breaks this code! Are there any suggestions from you'all on how I could go about modifying this code to work on reporting exactly how many image files are present?
On Windows 10, the Type values for .jpg and .png files are JPEG image and PNG image respectively. What OS are you using?
Also, Type doesn't actually analyze the file, you could have a virus.exe file in the folder that has been renamed to virus.jpg, and the Type value will still show it as JPEG. So if the function is indented to check user uploaded content to ensure images are actually images, the Type value will be of no use. If you have root access you could install a COM DLL that uses a program such as ExifTool to properly analyze files (https://github.com/as08/ClassicASP.ExifTool), however that would be a complete rewrite.
But assuming you're not looking to check if an image file is actually an image file, you could just split the filename extensions and use Select Case to count the image files if your OS is returning just XXX file and no longer XXX image in the Type value (alternatively you could split the Type value, but you'd still need to check for valid image file extensions):
Dim oFSO, oFolder, oSubFolder, oFileName, iFileCount, oFileNameSplit
Set oFSO = Server.CreateObject("Scripting.FileSystemObject")
Set oFolder = oFSO.GetFolder(Server.MapPath(sCurrentDirectoryPath))
Set oSubFolder = oFolder.Files
iFileCount = 0
For Each oFileName In oSubFolder
oFileNameSplit = Split(oFileName.Name,".")
If uBound(oFileNameSplit) > 0 Then
Select Case Trim(lCase(oFileNameSplit(uBound(oFileNameSplit))))
Case "jpg", "jpeg", "png", "gif" ' Maybe add some more extensions...
iFileCount = iFileCount + 1
End Select
End If
Next
Set oFSO = Nothing
Set oFolder = Nothing
Set oSubFolder = Nothing
Response.Write(iFileCount)
I have an R script that is being run from an Excel workbook via a button that is linked to a VBA script.
The problem is every time the R script encounters an error - say it does not find one of the files it was supposed to read - the Shell / cmd window the R script is running in closes down instantly. The problem with that is you cannot see any clues as to why it failed. I then have to debug it manually by modifying the code and running in RStudio to find the errors - usually I have to do this for other people that do not know R.
The VBA code I use was copied and modified from one of the SO posts I found here. I am not very proficient in VBA and do not understand a lot of the code so I'm looking for a simple solution to this. My VBA code is this:
Option Explicit
Public Sub RunRscript()
ActiveWorkbook.Save
Dim shell As Object
Set shell = VBA.CreateObject("WScript.Shell")
Dim waitTillComplete As Boolean: waitTillComplete = True
Dim style As Integer: style = 1
Dim scriptPath As String
scriptPath = Range("F5").Value
Dim argument As String
argument = Range("F3").Value
Dim path As String
path = """C:\Program Files\R\R-3.4.2\bin\Rscript.exe"" """ & scriptPath & """ """
& argument & """"
ActiveWorkbook.Save
Dim errorcode As Integer
errorcode = shell.Run(path, style, waitTillComplete)
ActiveWorkbook.Save
End Sub
scriptPath points to the path of the R script and argument is an argument I pass to the R script.
I have tried passing the usual arguments to keep the cmd window open but I didn't manage to figure it out. This is also complicated by the fact that as mentioned I do not understand VBA syntax very well and the 'path' variable being very convoluted because of those endless double quotes.
You might use
errorcode = shell.Run("cmd /k " & path, style, waitTillComplete)
instead of
errorcode = shell.Run(path, style, waitTillComplete)
We open a new instance of the command-line tool, thus can use its parameters. The parameter /k keeps the cmd-window open (use /c to close). After the cmd-parameter we add the script to be executed.
But there is one problem: if you close the cmd-window, VBA throws an overflow error. I use a flag in my Excel sheet to switch between debug mode and normal mode:
debugging = Range("N5").Value 'True/False
If debugging Then
errorCode = shell.Run("cmd /k " & path, style, waitTillComplete)
Else
errorCode = shell.Run(path, style, waitTillComplete)
End If
If the script fails I rerun it setting debug mode to True in a cell of the Excel sheet.
Based on this comment:
#FreeMan, the output of the R script is actually a series of Excel workbooks that it opens, prints data in and then saves. it reads a list with the paths of all the files it needs to read as an input to generate the output data required to print in excel. Sometimes, one of the paths in that list is wrong, so the program stops halfway and there is no clue as to why for the user. (the reason could be something else as well). It would be good if I could pass the text that is generated in shell / cmd automatically to a notepad / textpad file at least, so the user could then open and check
It sounds like the best bet may be to have your R script validate the paths/files prior to attempting to do its processing. I'm barely familiar with R, but what I know of it there should be a library somewhere that will allow you to test for the existence of a path and/or a file on that path. If it doesn't exist, the script would simply put an error message in the file it was supposed to create/update indicating that it couldn't find the requested path/file, or it could write that message to an error log that could be opened by your VBA code at the completion of its processing.
I'm having issues when trying to read in a binary file I've previously written into another program. I have been able to open it and read it to an array with out compilation errors, however, the array is not populated (all 0's). Any suggestions or thoughts would be great. Here is the open/read statement I'm using:
allocate(dummy(imax,jmax))
open(unit=io, file=trim(input), form='binary', access='stream', &
iostat=ioer, status='old', action='READWRITE')
if(ioer/=0) then
print*, 'Cannot open file'
else
print*,'success opening file'
end if
read(unit=io, fmt=*, iostat=ioer) dummy
j=0
k=0
size: do j=1, imax
do k=1, jmax
if(dummy(j,k) > 0.) print*,dummy(j,k)
end do
end do size
Please let me know if you need more info.
Here is how the file is originally written:
out_file = trim(output_dir)//'SEVIRI_FRP_.08deg_'//trim(season)//'.bin'
print*, out_file
print*, i_max,' i_max,',j_max,' j_max'
open (io, file = out_file, access = 'direct', status = 'replace', recl = i_max*j_max*4)
write(io, rec = 1) sev_frp
write(io, rec = 2) count_sev_frp
write(io, rec = 3) sum_sev_frp
check: do n=1, i_max
inna: do m=1, j_max
!if (sev_frp(n,m) > 0) print*, count_sev_frp(n,m)
end do inna
end do check
print*,'n-',n,'m-',m
close(io)
First of all the form takes two possible values as far as I know: "FORMATTED" or "UNFORMATTED".
Second, to read, you should use a open that is symmetric to the open statement that you used to write the file, Unless you know exactely what you are doing. I suggest that for reading, you open with:
open(unit=io, file=trim(input), access='direct', &
iostat=ioer, status='old', action='READ', recl = i_max*j_max*4)
That corresponds to the open statement that you used to save the file.
As innoSPG says, you have a mismatch in the way the file is written and how it is read.
An external file may be connected with one of three access methods: sequential; direct; stream. Further, a connection may be formatted or unformatted.
When the file is opened for writing it uses the direct access method with unformatted records. The records are unformatted because this is the default (in the abscence of the form= specifier).
When you open the file for reading you use the non-standard extension of form="binary" and stream access. There is possibly nothing wrong with this, but it does require care.
However, with the read statements you are using formatted (list-directed) input. This will not be allowed.
The way suggested in the previous answer, of using a similar access method and record length will require a further change to the code. [You'll also need to set the value of the record length somehow.]
Not only will you need to remove the format, to match the unformatted records written, but you'll want to use the rec= specifier to access the records of the file.
Finally, if you are using the iostat= specifier you really should check the resulting value.
I have DotNetZip installed and running fine on a Windows 2008 server.
Using a classic ASP page, I want to bundle a bunch of comma-delimited files to a user and send it over in a zip file.
The following code works fine but it stores all the path information so the files inside the zip file are located in some ridiculous directory like C:\Inetpub\wwwroot\appname\_temp\
I'm using the following code:
Set objZip = CreateObject("Ionic.Zip.ZipFile")
sFileArray = Split(sFileArray, "|")
For iCount = 0 To UBound(sFileArray)
If sFileArray(iCount) <> "" Then
objZip.AddFile sFileArray(iCount)
End If
Next
objZip.Name = sFilePath & "test.zip"
objZip.Save()
objZip.Dispose()
Set objZip = Nothing
I see that the AddFile method allows you to specify where you want the added file to reside in the zip file if you add a second parameter. According to the documentation objZip.AddFile sFileArray(iCount), "" should put the file in the root of the zip file.
However, when I add that parameter, I get the following error:
Wrong number of arguments or invalid property assignment: 'objZip.AddFile'
Anyone have any idea what I'm doing wrong?
Thanks.
I think you are misinterperting the documentation. If the second parameter is null then the directory path of the file being added is used. If the second parameter is an empty string "" then the file is added to the root level in the zip. A quick look into the Ioniz.zip.dll shows that the single parameter override of AddFile method simply calls the the double parameter override with the second parameter set to null.
Hence your add file should look like:
objZip.AddFile sFileArray(iCount), ""
to get the result you are after.
I'm trying to output a PDF using server side javascript (ASP). The current method I'm using is:
xfile=Server.MapPath(lib.fso.GetTempName())
xf=lib.fopen(xfile,"wb");
lib.fwrite(xf,this.buffer);
lib.fclose(xf);
outB = Server.CreateObject("ADODB.Stream")
outB.Type = 1
outB.Open()
outB.LoadFromFile (xfile)
Response.BinaryWrite(outB.Read())
outB.Close()
lib.fso.DeleteFile(xfile);
This works, but requires write access on the server. Is there a way to do the same thing without writing to a file?
I havn't been able to figure out how to convert the string this.buffer into a array of byte that I can then write using Response.BinaryWrite without writing to a file first.
Why not simply use:-
Response.Write(this.buffer)
Assuming the codepage of the response is set correctly (I.e., its the same as in the Locale that the VBScript is running in) then Response.Write should do the same conversion that your StringToMultiByte is doing.
I suspect you've tried this and is hasn't worked. If so I really think you need to look into why that is rather attempt this strange usage of BinaryWrite. Currently your solution is going to kill your server.
My solution was to use VBScript.
replace the above code with:
Response.BinaryWrite(StringToMultiByte(this.buffer));
and add this to the end of the file:
<script language="vbscript" runat="server">
function StringToMultiByte(S)
Dim i, MultiByte
For i=1 To Len(S)
MultiByte = MultiByte & ChrB(Asc(Mid(S,i,1)))
Next
StringToMultiByte = MultiByte
End function
</script>