I have a custom package I want to install automatically in my docker using expect.
The first thing the package asks me to do is press Enter to continue, then it prints another 2 empty lines then it waits for an input.
My expect script :
#!/usr/bin/expect -f
set timeout -1
spawn ./install
expect "\n"
send -- "\n"
But as you can see in the image, it just runs the installer and exits.
I tried removing the expect "\n" so only send -- "\n" will execute but now even the install message doesn't appear (tried with set timeout 1000 before send and it also didn't work)
Any ideas?
P.S : This is a link to the package if anyone wants to have a go at it:
https://www.bayometric.com/downloads/digital-persona/DP_UareU_Linux223_20140429.2.zip
(the installer is inside DP-UareU-RTE-2.2.3-1.20140429_1533.tar.gz)
expect "\n" match a linefeed exactly, I think this is not what your program is sending.
To wait for a Shell prompt you can use expect "%" or expect "*" to match anything.
If you need to make sure you're dealing with the right prompt you may be able to use something like expect "*Linux Installation*".
Also don't send \n but \r for the enter key :
#!/usr/bin/expect
spawn ./install
expect "*Linux Installation*"
send "\r"
expect eof
Note that the default flag is -gl for glob pattern matching but you can also use the -re flag for regular expression matching.
Related
I'm trying to add helpful messages for arbitrary builds. If the build fails the user can, for example, install the package with different arguments.
My interface idea is to provide a function, build-with-message, that would be called with something like this:
build-with-message
''Building ${pkg.name}. Alternative invocations are: ..''
pkg
My implementation is based on builtins.seq
build-with-message = msg : pkg :
seq
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'')
pkg;
When I build a package with build-with-message I never see the message. My hunch is that seq evaluates the runCommand far enough to see that a set is returned and moves on to building the package. I tried with deepSeq as well, but a deepSeq build fails on runCommand. I also tried calling out some attributes from the runCommand, e.g.
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'').drvPath
(self.runCommand "issue-message" {} ''mkdir $out; echo ${msg}'').out
My thought being that calling for one of these would prompt the rest of the build. Perhaps I'm not calling the right attribute, but in any case the ones I've tried don't work.
So:
Is there a way to force the runCommand to build in the above scenario?
Is there already some builtin that just lets me issue messages on top of arbitrary builds?
Here's me answering my own question again, consider this a warning.
Solution:
I've in-lined some numbered comments to help with the explanation.
build-with-message = msg : pkg :
let runMsg /*1*/ = self.runCommand "issue-message"
{ version = toString currentTime; /*2*/ } ''
cat <<EOF
${msg}
EOF
echo 0 > $out /*3*/
'';
in seq (import runMsg /*4*/) pkg; /*5*/
Explanation:
runMsg is the derivation that issues the message.
Adding a version based on the current time ensures that the build of runMsg will not be in /nix/store. Otherwise, each unique message will only be issued for the first build.
After the message is printed, a 0 is saved to file as the output of the derivation.
The import loads runMsg--a derivation, and therefore serialized as the path $out. Import expects a nix expression, which in this case is just the number 0 (a valid nix expression).
Now, since the runMsg output will not be available until after it has been built, the seq command will build it (issuing the message) and then build pkg.
Discussion:
I take note of Robert Hensing's comment to my question--this may not be something Nix was not intended for. I'm not arguing against that. Moving on.
Notice that issuing a message like so will add a file to your nix store for every message issued. I don't know if the message build will be garbage collected while pkg is still installed, so there's the possibility of polluting the nix store if such a pattern is overused.
I also think it's really interesting that the result of the runMsg build was to install a nix expression. I suppose this opens the door to doing useful things.
I want to call run a file called csvplot.vbs (from this site) to turn a .csv file I have written using dxl (has 5 columns, each with a heading and then just numerical data) into a graph (stored as .png).
I have run the following instruction directly through cmd with success:
#echo off
cscript //nologo C:\Users\Administrator\csvplot.vbs C:\PROGRA~1\IBM\Rational\DOORS\9.6\lib\dxl\addins\Verification\Statistics\statGenTest_Top_Level.csv C:\PROGRA~1\IBM\Rational\DOORS\9.6\lib\dxl\addins\Verification\Statistics\statGenTest_Top_Level.png 800 600 1 3 1 4 1 5
pause
This produces the desired .png file.
What I want, however, is to be able to execute this through DOORS, so that whenever the script that generates the raw data is run, it also produces a graph.
What I have is this as my test case:
string echostr = "#echo off"
string commands = "cscript //nologo C:\\Users\\Administrator\\csvplot.vbs C:\\PROGRA~1\\IBM\\Rational\\DOORS\\9.6\\lib\\dxl\\addins\\Verification\\Statistics\\statGenTest_Top_Level.csv C:\\PROGRA~1\\IBM\\Rational\\DOORS\\9.6\\lib\\dxl\\addins\\Verification\\Statistics\\statGenTest_Top_Level.png 800 600 1 3 1 4 1 5"
system("cmd /c start #echo off") // doesn't recognise echo command
system("cmd /c start " commands "")
I get an error:
"Windows cannot find '#echo'. Make sure you typed the name correctly,
and then try again."
I am at a loss on how to get the script to run though cmd from dxl, and I would appreciate any help. I've only had one previous foray into system() prompts through dxl, and it was only to open a .pdf. In the meantime I will keep trying to work this out. Please let me know if I can provide any further information.
Edit: Further Information
#echo: I removed the # to see how it operates, it brings up a blank
cmd window and performs no further action. In order to even run the things in the points below, I left the # off.
I deleted "/c start" from the second system() line: this opens one command line with the usual white text at the top, and a second over the top that is completely blank.
I changed the first line as follows, and commented out the second:
system("cmd /c start echo off" "\n" commands "")
--- this got a similar result to the second dot-point, but only with one cmd window, the black (no text one)
If I don't include the "\n" marker then I get a cmd window with text of "off" commands (where commands is the defined string above).
If I only have the system("cmd /c start " commands "") line, and not the echo line, then a cmd window briefly flashes and disappears and no further results demonstrating the success of the script appear.
So my issue is this: I know this script works when run directly through command line, the problem I have is that I cannot now run it through dxl.
I have developed a solid work-around that does exactly what I need.
The issue was that the input I had dxl writing was not going through command line correctly.
Knowing that the script ran from cmd correctly and, in turn, that the script executed from a batch file correctly, and that I could run the batch file from dxl, my solution was as follows:
Define the paths in dxl using the format C:\PROGRA~1\PATHNAME\
Using the Stream write() command to write the instructions directly
to a .bat file
Then using the system() command to run the .bat file
I have included some of my code, so that maybe it might help someone attempting to do the same thing. (I'll gladly take any advice on better programming conventions.)
// functions used: genFileName(), assume if a variable is not declared here, it was declared under my globals
// genFileName() returns a string of the file name, replacing any " " with "_" so cmd doesn't cry when I run it
string basename = genFileName()
string fcsv = basename ".csv"
string csvPath = "blahblahthefilepath" fcsv
if(fileExists_(csvPath)) isFile = true
Stream fOut = append(csvPath)
// === if file does not exist, create, give column names
if( !isFile){
fOut << "Date and Time,count1,count2,count3,count4" "\n"
}
else ack ("File name exists, append stats to file?" // may not be necessary
// === print to file ===
fOut << datetime "," ctot "," ctc "," cti "," ctnc "\n"
// ===== Create Batch file to run grapher ===
string columnsToPlot = "1 3 1 4 1 5" // ==> may develop this to allow user to choose
string graphDim = "800 600" // ==> px dim, may develop for user choice
string fbat = basename ".bat"
string batPath = "blahblahthefilepath"
Stream batOut = write(batPath fbat)
batOut << "#echo off" "\n"
batOut << "title Batch file to plot statistics for " fcsv "\n"
batOut << "cscript //nologo " batPath "csvplot.vbs " batPath fcsv " " batPath basename ".png " graphDim " " columnsToPlot ""
system("cmd /c start " batPath fbat "")
// some infoBox feedback DB to tell the user that the files were created
Good luck to anyone else who is attempting something similar, and I hope this is of use to someone.
Does running the dxl script without the # in front of the echo command work?
Although I am quite familiar with Tcl this is a beginner question. I would like to read and write from a pipe. I would like a solution in pure Tcl and not use a library like Expect. I copied an example from the tcl wiki but could not get it running.
My code is:
cd /tmp
catch {
console show
update
}
proc go {} {
puts "executing go"
set pipe [open "|cat" RDWR]
fconfigure $pipe -buffering line -blocking 0
fileevent $pipe readable [list piperead $pipe]
if {![eof $pipe]} {
puts $pipe "hello cat program!"
flush $pipe
set got [gets $pipe]
puts "result: $got"
}
}
go
The output is executing go\n result:, however I would expect that reading a value from the pipe would return the line that I have sent to the cat program.
What is my error?
--
EDIT:
I followed potrzebie's answer and got a small example working. That's enough to get me going. A quick workaround to test my setup was the following code (not a real solution but a quick fix for the moment).
cd /home/stephan/tmp
catch {
console show
update
}
puts "starting pipe"
set pipe [open "|cat" RDWR]
fconfigure $pipe -buffering line -blocking 0
after 10
puts $pipe "hello cat!"
flush $pipe
set got [gets $pipe]
puts "got from pipe: $got"
Writing to the pipe and flushing won't make the OS multitasking immediately leave your program and switch to the cat program. Try putting after 1000 between the puts and the gets command, and you'll see that you'll probably get the string back. cat has then been given some time slices and has had the chance to read it's input and write it's output.
You can't control when cat reads your input and writes it back, so you'll have to either use fileevent and enter the event loop to wait (or periodically call update), or periodically try reading from the stream. Or you can keep it in blocking mode, in which case gets will do the waiting for you. It will block until there's a line to read, but meanwhile no other events will be responded to. A GUI for example, will stop responding.
The example seem to be for Tk and meant to be run by wish, which enters the event loop automatically at the end of the script. Add the piperead procedure and either run the script with wish or add a vwait command to the end of the script and run it with tclsh.
PS: For line-buffered I/O to work for a pipe, both programs involved have to use it (or no buffering). Many programs (grep, sed, etc) use full buffering when they're not connected to a terminal. One way to prevent them to, is with the unbuffer program, which is part of Expect (you don't have to write an Expect script, it's a stand-alone program that just happens to be included with the Expect package).
set pipe [open "|[list unbuffer grep .]" {RDWR}]
I guess you're executing the code from http://wiki.tcl.tk/3846, the page entitled "Pipe vs Expect". You seem to have omitted the definition of the piperead proc, indeed, when I copy-and-pasted the code from your question, I got an error invalid command name "piperead". If you copy-and-paste the definition from the wiki, you should find that the code works. It certainly did for me.
all! I'm trying to compile a program using PowerShell, but the command is being parsed strangely.
This command executes correctly in cmd.exe:
dmd -od"bin" -of"bin\convHull.exe" -I"src" "src\concSort.d" "src\fileParser.d" "src\main.d" "src\pointLogic.d" "src\quickHull.d" "src\stupidHull.d" -D -O -release
But PowerShell executes it as: (blue, navy, purple texts as they appear in PowerShell ISE)
dmd -od"bin" -of"bin\convHull.exe" -I"src" "src\concSort.d" "src\fileParser.d" "src\main.d" "src\pointLogic.d" "src\quickHull.d" "src\stupidHull.d" -D -O -release
This spits the following error:
The string starting:
At line:1 char:147
+ dmd -od"bin" -of"bin\convHull.exe" -I"src" "src\concSort.d" "src\fileParser.d" "src\main.d"
"src\pointLogic.d" "src\quickHull.d" "src\stupidHull.d <<<< " -D -O -release
is missing the terminator: ".
At line:1 char:163
So it seems to be interpreting a period as a quote. This is peculiar. Has anyone else had this problem with PowerShell?
Things I've tried:
escaping quotes
making sure all quotes are "straight quotes" and not angled
putting a space before quotes (parses correctly, but the program doesn't understand the arguments.)
Thanks,
Charles.
I believe this should do the trick (newlines added for clarity only, and removal of extra quotes):
dmd '-od"bin"' '-of"bin\convHull.exe"' '-I"src"'
src\concSort.d src\fileParser.d src\main.d src\pointLogic.d src\quickHull.d src\stupidHull.d
-D -O -release
Note that in the case where a quote (") is to be passed as part of the argument itself, I surrounded the entire argument with single quotes ('). From the experimentation below it can be seen that only -of"..." needs the quotes about it.
Happy coding.
I can't find a good reference on this exact production, however note the following parsings:
-x"w." -> error: " expected (last " is special)
-x"w."" -> -x"w and ."" (the . starts a new token and the " in that starts
a quote; however, the quotes are not removed)
'-x"w."' -> -x"w." (extra quote fine, neither special)
-x"w" -> -x"w" (no . and " not special)
-x"w"" -> -x"w"" (no . and " not special)
a".b" -> a.b (didn't start with `-`, quotes removed)
a".b -> error: " expected (" is special)
So it does indeed appear to have something to do with the . and - combination (and it might not be exclusive). From the above I believe that a token starting with - does not include the . character as a valid character in the token so the lexer terminates said token and starts a new token -- easily provable with a good EBNF reference, which I don't have.
The best I can find is Appendix C: The PowerShell Grammar:
The ParameterToken rule is used to match cmdlet parameters such as -foo or -
boolProp: . Note that this rule will also match --foobar, so this rule has
to be checked before the --token rule.
<ParameterToken> = -[:letter:]+[:]{0 |1}
However, this is incomplete at best and does not even include a definition of "letter".
I don't have the executable, but this seems to want to work.
$cmd = #'
dmd -od"bin" -of"bin\convHull.exe" -I"src" "src\concSort.d" "src\fileParser.d" "src\main.d" "src\pointLogic.d" "src\quickHull.d" "src\stupidHull.d" -D -O -release
'#
&$cmd
I wrote the following two functions, and call the second ("callAndWait") from JavaScript running inside Windows Script Host. My overall intent is to call one command line program from another. That is, I'm running the initial scripting using cscript, and then trying to run something else (Ant) from that script.
function readAllFromAny(oExec)
{
if (!oExec.StdOut.AtEndOfStream)
return oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
return "STDERR: " + oExec.StdErr.ReadLine();
return -1;
}
// Execute a command line function....
function callAndWait(execStr) {
var oExec = WshShell.Exec(execStr);
while (oExec.Status == 0)
{
WScript.Sleep(100);
var output;
while ( (output = readAllFromAny(oExec)) != -1) {
WScript.StdOut.WriteLine(output);
}
}
}
Unfortunately, when I run my program, I don't get immediate feedback about what the called program is doing. Instead, the output seems to come in fits and starts, sometimes waiting until the original program has finished, and sometimes it appears to have deadlocked. What I really want to do is have the spawned process actually share the same StdOut as the calling process, but I don't see a way to do that. Just setting oExec.StdOut = WScript.StdOut doesn't work.
Is there an alternate way to spawn processes that will share the StdOut & StdErr of the launching process? I tried using "WshShell.Run(), but that gives me a "permission denied" error. That's problematic, because I don't want to have to tell my clients to change how their Windows environment is configured just to run my program.
What can I do?
You cannot read from StdErr and StdOut in the script engine in this way, as there is no non-blocking IO as Code Master Bob says. If the called process fills up the buffer (about 4KB) on StdErr while you are attempting to read from StdOut, or vice-versa, then you will deadlock/hang. You will starve while waiting for StdOut and it will block waiting for you to read from StdErr.
The practical solution is to redirect StdErr to StdOut like this:
sCommandLine = """c:\Path\To\prog.exe"" Argument1 argument2"
Dim oExec
Set oExec = WshShell.Exec("CMD /S /C "" " & sCommandLine & " 2>&1 """)
In other words, what gets passed to CreateProcess is this:
CMD /S /C " "c:\Path\To\prog.exe" Argument1 argument2 2>&1 "
This invokes CMD.EXE, which interprets the command line. /S /C invokes a special parsing rule so that the first and last quote are stripped off, and the remainder used as-is and executed by CMD.EXE. So CMD.EXE executes this:
"c:\Path\To\prog.exe" Argument1 argument2 2>&1
The incantation 2>&1 redirects prog.exe's StdErr to StdOut. CMD.EXE will propagate the exit code.
You can now succeed by reading from StdOut and ignoring StdErr.
The downside is that the StdErr and StdOut output get mixed together. As long as they are recognisable you can probably work with this.
Another technique which might help in this situation is to redirect the standard error stream of the command to accompany the standard output.
Do this by adding "%comspec% /c" to the front and "2>&1" to the end of the execStr string.
That is, change the command you run from:
zzz
to:
%comspec% /c zzz 2>&1
The "2>&1" is a redirect instruction which causes the StdErr output (file descriptor 2) to be written to the StdOut stream (file descriptor 1).
You need to include the "%comspec% /c" part because it is the command interpreter which understands about the command line redirect. See http://technet.microsoft.com/en-us/library/ee156605.aspx
Using "%comspec%" instead of "cmd" gives portability to a wider range of Windows versions.
If your command contains quoted string arguments, it may be tricky to get them right:
the specification for how cmd handles quotes after "/c" seems to be incomplete.
With this, your script needs only to read the StdOut stream, and will receive both standard output and standard error.
I used this with "net stop wuauserv", which writes to StdOut on success (if the service is running)
and StdErr on failure (if the service is already stopped).
First, your loop is broken in that it always tries to read from oExec.StdOut first. If there is no actual output then it will hang until there is. You wont see any StdErr output until StdOut.atEndOfStream becomes true (probably when the child terminates). Unfortunately, there is no concept of non-blocking I/O in the script engine. That means calling read and having it return immediately if there is no data in the buffer. Thus there is probably no way to get this loop to work as you want. Second, WShell.Run does not provide any properties or methods to access the standard I/O of the child process. It creates the child in a separate window, totally isolated from the parent except for the return code. However, if all you want is to be able to SEE the output from the child then this might be acceptable. You will also be able to interact with the child (input) but only through the new window (see SendKeys).
As for using ReadAll(), this would be even worse since it collects all the input from the stream before returning so you wouldn't see anything at all until the stream was closed. I have no idea why the example places the ReadAll in a loop which builds a string, a single if (!WScript.StdIn.AtEndOfStream) should be sufficient to avoid exceptions.
Another alternative might be to use the process creation methods in WMI. How standard I/O is handled is not clear and there doesn't appear to be any way to allocate specific streams as StdIn/Out/Err. The only hope would be that the child would inherit these from the parent but that's what you want, isn't it? (This comment based upon an idea and a little bit of research but no actual testing.)
Basically, the scripting system is not designed for complicated interprocess communication/synchronisation.
Note: Tests confirming the above were performed on Windows XP Sp2 using Script version 5.6. Reference to current (5.8) manuals suggests no change.
Yes, the Exec function seems to be broken when it comes to terminal output.
I have been using a similar function function ConsumeStd(e) {WScript.StdOut.Write(e.StdOut.ReadAll());WScript.StdErr.Write(e.StdErr.ReadAll());} that I call in a loop similar to yours. Not sure if checking for EOF and reading line by line is better or worse.
You might have hit the deadlock issue described on this Microsoft Support site.
One suggestion is to always read both from stdout and stderr.
You could change readAllFromAny to:
function readAllFromAny(oExec)
{
var output = "";
if (!oExec.StdOut.AtEndOfStream)
output = output + oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
output = output + "STDERR: " + oExec.StdErr.ReadLine();
return output ? output : -1;
}