Mixing
Tcl / Expect script driven by name pipe blocks/buffers output unexpectedly
I am trying to write an expect script that reacts to input from reading a pipe. Consider this example in file "contoller.sh":
#!/usr/bin/env expect
spawn bash --noprofile --norc
set timeout 3
set success 0
send "PS1='Prompt: 'r"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { exit 1 }
proc do { cmd } {
puts "Got command: $cmd"
set success 0
set timeout 3
send "$cmdr"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { puts "oops" }
}
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
fileevent $cpipe readable read_command
} else {
if { $cmd == "exit" } {
exp_close
exp_wait
exit 0
} elseif { $cmd == "ls" } {
do ls
} elseif { $cmd == "pwd" } {
do pwd
}
}
}
fileevent $cpipe readable read_command
vwait forever;
Suppose you do:
export CMDPIPE=~/.cmdpipe
mkfifo $CMDPIPE
./controller.sh
Now, from another terminal try:
export CMDPIPE=~/.cmdpipe
echo ls >> ${CMDPIPE}
echo pwd >> ${CMDPIPE}
In the first terminal the "Got command: ls/pwd" lines are printed immediately as soon as you press enter on each echo command, but there is no output from the spawned bash shell (no file listing and current directory). Now, try it once more:
echo ls >> ${CMDPIPE}
Suddenly output from the first two commands appears but 3rd command (second ls) is not visible. Keep going and you will notice that there is a "lag" in displayed output which seems to be "buffered" and then dumped at once later.
Why is this happening and how can I fix it?
tcl expect
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
add a comment |
I am trying to write an expect script that reacts to input from reading a pipe. Consider this example in file "contoller.sh":
#!/usr/bin/env expect
spawn bash --noprofile --norc
set timeout 3
set success 0
send "PS1='Prompt: 'r"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { exit 1 }
proc do { cmd } {
puts "Got command: $cmd"
set success 0
set timeout 3
send "$cmdr"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { puts "oops" }
}
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
fileevent $cpipe readable read_command
} else {
if { $cmd == "exit" } {
exp_close
exp_wait
exit 0
} elseif { $cmd == "ls" } {
do ls
} elseif { $cmd == "pwd" } {
do pwd
}
}
}
fileevent $cpipe readable read_command
vwait forever;
Suppose you do:
export CMDPIPE=~/.cmdpipe
mkfifo $CMDPIPE
./controller.sh
Now, from another terminal try:
export CMDPIPE=~/.cmdpipe
echo ls >> ${CMDPIPE}
echo pwd >> ${CMDPIPE}
In the first terminal the "Got command: ls/pwd" lines are printed immediately as soon as you press enter on each echo command, but there is no output from the spawned bash shell (no file listing and current directory). Now, try it once more:
echo ls >> ${CMDPIPE}
Suddenly output from the first two commands appears but 3rd command (second ls) is not visible. Keep going and you will notice that there is a "lag" in displayed output which seems to be "buffered" and then dumped at once later.
Why is this happening and how can I fix it?
tcl expect
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08
add a comment |
I am trying to write an expect script that reacts to input from reading a pipe. Consider this example in file "contoller.sh":
#!/usr/bin/env expect
spawn bash --noprofile --norc
set timeout 3
set success 0
send "PS1='Prompt: 'r"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { exit 1 }
proc do { cmd } {
puts "Got command: $cmd"
set success 0
set timeout 3
send "$cmdr"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { puts "oops" }
}
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
fileevent $cpipe readable read_command
} else {
if { $cmd == "exit" } {
exp_close
exp_wait
exit 0
} elseif { $cmd == "ls" } {
do ls
} elseif { $cmd == "pwd" } {
do pwd
}
}
}
fileevent $cpipe readable read_command
vwait forever;
Suppose you do:
export CMDPIPE=~/.cmdpipe
mkfifo $CMDPIPE
./controller.sh
Now, from another terminal try:
export CMDPIPE=~/.cmdpipe
echo ls >> ${CMDPIPE}
echo pwd >> ${CMDPIPE}
In the first terminal the "Got command: ls/pwd" lines are printed immediately as soon as you press enter on each echo command, but there is no output from the spawned bash shell (no file listing and current directory). Now, try it once more:
echo ls >> ${CMDPIPE}
Suddenly output from the first two commands appears but 3rd command (second ls) is not visible. Keep going and you will notice that there is a "lag" in displayed output which seems to be "buffered" and then dumped at once later.
Why is this happening and how can I fix it?
tcl expect
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
I am trying to write an expect script that reacts to input from reading a pipe. Consider this example in file "contoller.sh":
#!/usr/bin/env expect
spawn bash --noprofile --norc
set timeout 3
set success 0
send "PS1='Prompt: 'r"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { exit 1 }
proc do { cmd } {
puts "Got command: $cmd"
set success 0
set timeout 3
send "$cmdr"
expect {
"Prompt: " { set success 1 }
}
if { $success != 1 } { puts "oops" }
}
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open "$::env(CMDPIPE)" r]
fconfigure $cpipe -blocking 0
fileevent $cpipe readable read_command
} else {
if { $cmd == "exit" } {
exp_close
exp_wait
exit 0
} elseif { $cmd == "ls" } {
do ls
} elseif { $cmd == "pwd" } {
do pwd
}
}
}
fileevent $cpipe readable read_command
vwait forever;
Suppose you do:
export CMDPIPE=~/.cmdpipe
mkfifo $CMDPIPE
./controller.sh
Now, from another terminal try:
export CMDPIPE=~/.cmdpipe
echo ls >> ${CMDPIPE}
echo pwd >> ${CMDPIPE}
In the first terminal the "Got command: ls/pwd" lines are printed immediately as soon as you press enter on each echo command, but there is no output from the spawned bash shell (no file listing and current directory). Now, try it once more:
echo ls >> ${CMDPIPE}
Suddenly output from the first two commands appears but 3rd command (second ls) is not visible. Keep going and you will notice that there is a "lag" in displayed output which seems to be "buffered" and then dumped at once later.
Why is this happening and how can I fix it?
tcl expect
tcl expect
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
edited Nov 20 '18 at 11:39
Alexandros
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
asked Nov 19 '18 at 19:30
AlexandrosAlexandros
1,2101122
1,2101122
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08
add a comment |
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08
add a comment |
1 Answer
1
active
oldest
votes
According to fifo(7):
Normally, opening the FIFO blocks until the other end is opened also.
So, in the proc read_command, it's blocking on set cpipe [open "$::env(CMDPIPE)" r] and does not get the chance to display the spawned process's output until you echo ... >> ${CMDPIPE} again.
To work it around, you can open the FIFO (named pipe) in non-blocking mode:
set cpipe [open "$::env(CMDPIPE)" {RDONLY NONBLOCK} ]
This is also mentioned in fifo(7):
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no one has opened on the write side yet ...
The following is the simplified version of your code and it works fine for me (tested on Debian 9.6).
spawn bash --norc
set timeout -1
expect -re {bash-[.0-9]+[#$] $}
send "PS1='P''rompt: 'r"
# ^^^^
expect "Prompt: "
proc do { cmd } {
send "$cmdr"
if { $cmd == "exit" } {
expect eof
exit
} else {
expect "Prompt: "
}
}
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
} else {
do $cmd
}
}
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
vwait forever
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it'sopenwhich blocks sofconfigure -blocking 0would not help here.
– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
|
show 4 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381402%2ftcl-expect-script-driven-by-name-pipe-blocks-buffers-output-unexpectedly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
According to fifo(7):
Normally, opening the FIFO blocks until the other end is opened also.
So, in the proc read_command, it's blocking on set cpipe [open "$::env(CMDPIPE)" r] and does not get the chance to display the spawned process's output until you echo ... >> ${CMDPIPE} again.
To work it around, you can open the FIFO (named pipe) in non-blocking mode:
set cpipe [open "$::env(CMDPIPE)" {RDONLY NONBLOCK} ]
This is also mentioned in fifo(7):
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no one has opened on the write side yet ...
The following is the simplified version of your code and it works fine for me (tested on Debian 9.6).
spawn bash --norc
set timeout -1
expect -re {bash-[.0-9]+[#$] $}
send "PS1='P''rompt: 'r"
# ^^^^
expect "Prompt: "
proc do { cmd } {
send "$cmdr"
if { $cmd == "exit" } {
expect eof
exit
} else {
expect "Prompt: "
}
}
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
} else {
do $cmd
}
}
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
vwait forever
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it'sopenwhich blocks sofconfigure -blocking 0would not help here.
– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
|
show 4 more comments
According to fifo(7):
Normally, opening the FIFO blocks until the other end is opened also.
So, in the proc read_command, it's blocking on set cpipe [open "$::env(CMDPIPE)" r] and does not get the chance to display the spawned process's output until you echo ... >> ${CMDPIPE} again.
To work it around, you can open the FIFO (named pipe) in non-blocking mode:
set cpipe [open "$::env(CMDPIPE)" {RDONLY NONBLOCK} ]
This is also mentioned in fifo(7):
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no one has opened on the write side yet ...
The following is the simplified version of your code and it works fine for me (tested on Debian 9.6).
spawn bash --norc
set timeout -1
expect -re {bash-[.0-9]+[#$] $}
send "PS1='P''rompt: 'r"
# ^^^^
expect "Prompt: "
proc do { cmd } {
send "$cmdr"
if { $cmd == "exit" } {
expect eof
exit
} else {
expect "Prompt: "
}
}
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
} else {
do $cmd
}
}
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
vwait forever
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it'sopenwhich blocks sofconfigure -blocking 0would not help here.
– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
|
show 4 more comments
According to fifo(7):
Normally, opening the FIFO blocks until the other end is opened also.
So, in the proc read_command, it's blocking on set cpipe [open "$::env(CMDPIPE)" r] and does not get the chance to display the spawned process's output until you echo ... >> ${CMDPIPE} again.
To work it around, you can open the FIFO (named pipe) in non-blocking mode:
set cpipe [open "$::env(CMDPIPE)" {RDONLY NONBLOCK} ]
This is also mentioned in fifo(7):
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no one has opened on the write side yet ...
The following is the simplified version of your code and it works fine for me (tested on Debian 9.6).
spawn bash --norc
set timeout -1
expect -re {bash-[.0-9]+[#$] $}
send "PS1='P''rompt: 'r"
# ^^^^
expect "Prompt: "
proc do { cmd } {
send "$cmdr"
if { $cmd == "exit" } {
expect eof
exit
} else {
expect "Prompt: "
}
}
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
} else {
do $cmd
}
}
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
vwait forever
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
According to fifo(7):
Normally, opening the FIFO blocks until the other end is opened also.
So, in the proc read_command, it's blocking on set cpipe [open "$::env(CMDPIPE)" r] and does not get the chance to display the spawned process's output until you echo ... >> ${CMDPIPE} again.
To work it around, you can open the FIFO (named pipe) in non-blocking mode:
set cpipe [open "$::env(CMDPIPE)" {RDONLY NONBLOCK} ]
This is also mentioned in fifo(7):
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no one has opened on the write side yet ...
The following is the simplified version of your code and it works fine for me (tested on Debian 9.6).
spawn bash --norc
set timeout -1
expect -re {bash-[.0-9]+[#$] $}
send "PS1='P''rompt: 'r"
# ^^^^
expect "Prompt: "
proc do { cmd } {
send "$cmdr"
if { $cmd == "exit" } {
expect eof
exit
} else {
expect "Prompt: "
}
}
proc read_command {} {
global cpipe
if {[gets $cpipe cmd] < 0} {
close $cpipe
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
} else {
do $cmd
}
}
set cpipe [open cpipe {RDONLY NONBLOCK} ]
fileevent $cpipe readable read_command
vwait forever
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
edited Nov 20 '18 at 14:30
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
answered Nov 20 '18 at 4:47
pynexjpynexj
9,79341834
9,79341834
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it'sopenwhich blocks sofconfigure -blocking 0would not help here.
– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
|
show 4 more comments
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it'sopenwhich blocks sofconfigure -blocking 0would not help here.
– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I tried your suggestion but unfortunately behavior is the same. Please note that I was setting non-blocking mode already with "fconfigure $cpipe -blocking 0". Still even with your way of opening the pipe nothing changes.
– Alexandros
Nov 20 '18 at 11:14
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
I should add that if you copy-paste the example into a couple of bash terminals you will see that the [ puts "Got command: $cmd" ] statement is called immediately after you run echo to send a command. So the read-readiness seems fine. It's just the output of the actual command missing. This seems to me like it's a buffering problem, or something to do with an event loop in Tcl and/or expect which I am unaware of (don't know much tcl).
– Alexandros
Nov 20 '18 at 11:41
i tried it myself and it worked fine for me. it's
open which blocks so fconfigure -blocking 0 would not help here.– pynexj
Nov 20 '18 at 12:25
i tried it myself and it worked fine for me. it's
open which blocks so fconfigure -blocking 0 would not help here.– pynexj
Nov 20 '18 at 12:25
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
This is the change that fixes it: send "PS1='P''rompt: 'r"
– Alexandros
Nov 20 '18 at 13:20
2
2
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
FYI, I see the same behavior as you on Ubuntu. Updating my Cygwin which was 1.7-based replicated the same on my Windows box. So indeed there were 2 issues and you addressed both.
– Alexandros
Nov 22 '18 at 11:10
|
show 4 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381402%2ftcl-expect-script-driven-by-name-pipe-blocks-buffers-output-unexpectedly%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
FYI -- take a look at sexpect with which you can write Expect scripts with shell code only.
– pynexj
Nov 20 '18 at 14:08