StdoutRead

[PaulDG]

Please Look at this.

Local $s_source = "C:\Windows\*.*"
    Local $line = ""
    Local $foo = Run(@ComSpec & ' /c xcopy "' & $s_source & '" /L /Y', @SystemDir, @SW_SHOW, 2)
    While Not @error
        $line &= StdoutRead($foo)
    WEnd

    MsgBox(0, "STDOUT read:", $line)

When run in SciTe, all is well and the program does as expected.

When its compiled there is no output, a cmd windows appears for a split second and then goes away, the msgbox pops up empty.

The xcopy line is simplified for this demo, I have tried it with the propper full syntax, including the dest folder and the result is the same.

If you change the xcopy command for dir the compiled version works fine.

The problem was discovered using beta 87 and is present in beta 89.

I think this is also the same issue as is in this thread http://www.autoitscript.com/forum/index.ph...0&hl=StdoutRead

I would be greatfull of any help.

Thanks

[bboysza]

Please Look at this.

Local $s_source = "C:\Windows\*.*"
    Local $line = ""
    Local $foo = Run(@ComSpec & ' /c xcopy "' & $s_source & '" /L /Y', @SystemDir, @SW_SHOW, 2)
    While Not @error
        $line &= StdoutRead($foo)
    WEnd

    MsgBox(0, "STDOUT read:", $line)

When run in SciTe, all is well and the program does as expected.

When its compiled there is no output, a cmd windows appears for a split second and then goes away, the msgbox pops up empty.

The xcopy line is simplified for this demo, I have tried it with the propper full syntax, including the dest folder and the result is the same.

If you change the xcopy command for dir the compiled version works fine.

The problem was discovered using beta 87 and is present in beta 89.

I think this is also the same issue as is in this thread http://www.autoitscript.com/forum/index.ph...0&hl=StdoutRead

I would be greatfull of any help.

Thanks

Are you using Beta Run from within Scite? And then Bete-Compile as well? I had a similar issue when my au3check.dat was out of rev in the Defs\unstable\au3check folder in Scite.

[Jos]

can you try it with :

Local $foo = Run(@ComSpec & ' /k xcopy "' & $s_source & '" /L /Y', @SystemDir, @SW_SHOW, 2)

and see if it generates an error ?

[DaveF]

I can verify that this happens with the AutoitSC.bin versions mentioned above and my own "control" stub file based on beta version 63.

I can't do anything to debug at work, but I'll try to look at this at home, probably in the morning (= 14 hours from now.)

[jpm]

I can verify that this happens with the AutoitSC.bin versions mentioned above and my own "control" stub file based on beta version 63.

I can't do anything to debug at work, but I'll try to look at this at home, probably in the morning (= 14 hours from now.)

Without compiling you get it if you don't use Scite

[PaulDG]

@JdeB With /k it still dosnt work only now the cmd window dosnt close.

I have found that changing the 2 to a 3 at the end allows it to work. Hope that helps

I use beta run from within SciTe but i compile from the right click context menu, however i tried all methods and they all fail

Edited November 22, 2005 by PaulGX

[DaveF]

This is a strange case with XCOPY /Y because there's no output if there's no valid STDIN handle for XCOPY to inherit. By providing the /Y switch we're saying that there will be no input, so it shouldn't care about the state of STDIN. Most STDIN-aware programs would halt if given an open STDIN pipe handle until something was written to it, XCOPY /Y demands that there be a valid STDIN but then ignores it completely.

When the compiled script is run from a double-click there's no valid STDIN handle because Windows recognizes that the script is a Windows app, not a console app, and gives it the script a NULL handle to use for STDIN; XCOPY inherits the NULL handle from AutoIt so no output. When the script is run from SciTE the AutoIt3.exe process inherits a valid STDIN handle from SciTE and passes it on to XCOPY, so there's output from XCOPY. Further, we can get output from the compiled EXE by calling it on a command line in a DOS box (STDIN handle inherited from CMD.EXE), and there's no output from the uncompiled script if we run AutoIt3.exe and browse to the script (run as a Windows app, so NULL STDIN handle).

Without the /Y switch XCOPY would absolutely need STDIN open to receive input from the user, but XCOPY is odd in that even if the /Y switch is provided to declare that we don't want interactivity that it wants an open STDIN pipe (or at least a valid handle) anyway. By providing a 3 in the last parameter you're telling AutoIt to provide a STDIN pipe to the child process, which XCOPY seems to like and carry on, but most any other program would wait patiently for you to write something to the STDIN pipe and/or close it before it ran.

You can use ECHO to provide a no-op STDIN handle to XCOPY, a-la:

Local $foo = Run(@ComSpec & ' /c echo | xcopy "' & $s_source & '" /L /Y', @SystemDir, @SW_SHOW, 2)

...to get the command to work in your compiled script. Edited November 23, 2005 by DaveF

[jpm]

@DaveF

My God, That's an explanation. Non advanced user will always fall in this kind of problem. I am with them.

As I understand there is not a real solution that AutoIt can provide except explaining to use the echo |.

[PaulDG]

say that again?

No Seriously, thanks for taking the time to look at it and provide a great explanation. I understand most of that.....peer

So which do think is best, using a 3 at the end or the echo trick? I would guess the echo is better as theres no room for error or confusion in the future.

Paul

[ReFran]

..... So which do think is best, using a 3 at the end or the echo trick? ....

I would say 3.

So 2 and echo for experimental situations and 3 for a simple (just do it) working solution.

I don't remember that I ever have spent so much time on testing a statement, before I came to the idea to work with run(@comspec ....... ,,2). But I must admit it's maybe partly a personal/beginner problem.

Reinhard

Edited November 23, 2005 by ReFran

[DaveF]

Actually, this should probably be classified as a bug, though it's not AutoIt's fault. Looking again at Reinhard's similar post using find.exe I see that the echo | trick fixes that error, as well, so it is a problem for some command-line apps to be given a NULL STDIN handle.

Ah, after googling a little I found this blog entry that talks about this exact issue, actually citing xcopy and find.exe as troublemakers.

I've got a two-day holiday + two-day week-end starting tomorrow so I should be able to look at this.

[ReFran]

I've got a two-day holiday + two-day week-end starting tomorrow so I should be able to look at this.

Remember .... there are also other nice things than scripting, like ....

The "find" problem I solved with use FileReadLine() and stringInStr. I think it don't work slower for me, because with some lines more I could shorten the search. In a newer statement using PDFTK.exe to extract MetaData from a PDF I redirected to a %temp%-file. Maybe the better solution, because a big PDF with many bookmarks and fields may exceed the 64kb limit.

Anyway a hint in the helpfile also to the workarounds may help to avoid some confusion.

Have a nice long weekend, Reinhard

[user52]

Remember .... there are also other nice things than scripting, like ....

The "find" problem I solved with use FileReadLine() and stringInStr. I think it don't work slower for me, because with some lines more I could shorten the search. In a newer statement using PDFTK.exe to extract MetaData from a PDF I redirected to a %temp%-file. Maybe the better solution, because a big PDF with many bookmarks and fields may exceed the 64kb limit.

Anyway a hint in the helpfile also to the workarounds may help to avoid some confusion.

Have a nice long weekend, Reinhard

thanks letting me know about PDFTK.exe

http://www.pdfhacks.com/pdftk/pdftk-1.12.exe.zip

(i know this is an old post)

i can now update meta data using update_info, which is really just creating a copy of the pdf you specify with the meta data you specify

;command line code
;reads a.pdf meta data and outputs out.pdf with meta data specified in in.info
pdftk.exe a.pdf update_info in.info output out.pdf

; contents of in.info

InfoKey: Title
InfoValue: this is the NEW title
InfoKey: Author
InfoValue: this is the NEW author
InfoKey: Keywords
InfoValue: these are the NEW keywords
InfoKey: Subject
InfoValue: this is the NEW subject!

C:\pdftk-1.12>pdftk.exe __ a.pdf ___ update_info _ in.info ________ output __________ out.pdf

_____________ ^run pdftk _ ^pdf src_ ^command ____ ^new meta data _ ^output command _ ^pdf save name with in.info meta data

dump_data

Reads a single, input PDF file and reports vari-

ous statistics, metadata, bookmarks (a/k/a out-

lines), and page labels to the given output

filename or (if no output is given) to stdout.

Does not create a new PDF.

dump_data_fields

Reads a single, input PDF file and reports form

field statistics to the given output filename or

(if no output is given) to stdout. Does not

create a new PDF.

update_info <info data filename | - | PROMPT>

Changes the metadata stored in a single PDF's

Info dictionary to match the input data file.

The input data file uses the same syntax as the

output from dump_data. This does not change the

metadata stored in the PDF's XMP stream, if it

has one. For example: