[Solved] in havoc terminal emulator: yes causes broken pipes

[GNUser]

I'm experimenting with wayland on TCL14 x86_64.

Any shell script that relies on the  yes  command causes the  havoc  terminal emulator (with default configuration) to be littered with "Broken pipe" warnings. This includes the  tce-load  shell script:

Code: [Select]

$ tce-load -wil bmon
bmon.tcz.dep OK
Downloading: libconfuse.tcz
Connecting to gnuser.ddns.net (24.0.182.246:80)
saving to 'libconfuse.tcz'
libconfuse.tcz       100% |********************************| 24576  0:00:00 ETA
'libconfuse.tcz' saved
libconfuse.tcz: OK
yes: Broken pipe
Downloading: bmon.tcz
Connecting to gnuser.ddns.net (24.0.182.246:80)
saving to 'bmon.tcz'
bmon.tcz             100% |********************************| 49152  0:00:00 ETA
'bmon.tcz' saved
bmon.tcz: OK
yes: Broken pipe
I've never seen this issue when using  tce-load  in X session, regardless of the terminal emulator being used.

In the case of  tce-load  the warnings are cosmetic. However, the same issue causes some of my shell scripts (those that use  yes  to give encryption password to bcrypt) to hang indefinitely (with upward tick in CPU usage and laptop's fans coming on).

Any ideas what could be causing this "Broken pipe" warning related to  yes  (and how to fix it)?

[Juanito]

The same thing happens with the weston terminal.

[GNUser]

Good to know--so it isn't anything specific to havoc. I'll keep digging.

[patrikg]

Have you google it??
Can it be like this ??
https://stackoverflow.com/questions/20573282/hudson-yes-standard-output-broken-pipe
That the command that yes should send the yes to, have exit before ??
So what command is being used in the script to send yes to ??

Some text from the stackoverflow:

You could also report the bug against the component that runs the pipeline. The bug is in not restoring SIGPIPE to the default handler after the child is forked. It is what programs expect when they are run in a terminal on POSIX systems. Though I don't know whether there is a standard way to do it for a java-based program. jvm probably raises an exception for every write error so not-dying on SIGPIPE is not a problem for a java program.

So maybe it's the error comes from the shell that handling the signal correct.

[jazzbiker]

That the command that yes should send the yes to, have exit before ??

Of course, it is the only way for yes to exit :-)

@GNUser, busybox yes dies silently. Are You sure that exactly busybox yes is envoked? Can You ensure this with the full path call?

[GNUser]

Hi patrikg. Yes, I have done an internet search.
Hi jazzbiker. I don't have coreutils loaded. The only  yes  on my system is the busybox applet.

[curaga]

That stackoverflow link does look like the most likely explanation. IOW, it's a bug in those two terminals, havoc and weston terminal.

[GNUser]

IOW, it's a bug in those two terminals, havoc and weston terminal.

Darn. In that case, I created this trivial wrapper script for yes, which does away with the errors when using tce-load:

Code: [Select]

#!/bin/sh
exec /usr/bin/yes "$@" 2>/dev/nullBut that doesn't solve scripts where yes is needed multiple times in same pipeline. Even with the wrapper script, something like this:

Code: [Select]

yes "password" | bcrypt somefileseems to enter an endless loop, driving CPU usage way up. Workaround for this situation is this kludge:

Code: [Select]

i=1
while true; do
echo "password"
[ $i -eq 2 ] && break
i=$(( $i + 1 ))
done | bcrypt somefile
If I figure out how to properly fix the bug in the terminal emulators, I'll post it here.

[Juanito]

Why not file a bug report against weston or havoc?

[Rich]

Hi GNUser

... But that doesn't solve scripts where yes is needed multiple times in same pipeline. Even with the wrapper script, something like this:

Code: [Select]

yes "password" | bcrypt somefileseems to enter an endless loop, driving CPU usage way up. ...

What if you do it like this:

Code: [Select]

echo -e  "password\npassword" | bcrypt somefile

[GNUser]

Why not file a bug report against weston or havoc?

Good idea. Will do.

What if you do it like this:

Code: [Select]

echo -e  "password\npassword" | bcrypt somefile

Wow. Yes, that works and is much more elegant. Thank you!

[jazzbiker]

Darn. In that case, I created this trivial wrapper script for yes, which does away with the errors when using tce-load:

Code: [Select]

#!/bin/sh
exec /usr/bin/yes "$@" 2>/dev/nullBut that doesn't solve scripts where yes is needed multiple times in same pipeline. Even with the wrapper script, something like this:

Code: [Select]

yes "password" | bcrypt somefileseems to enter an endless loop, driving CPU usage way up. Workaround for this situation is this kludge:

Code: [Select]

i=1
while true; do
echo "password"
[ $i -eq 2 ] && break
i=$(( $i + 1 ))
done | bcrypt somefile
If I figure out how to properly fix the bug in the terminal emulators, I'll post it here.

Maybe trap instruction in the wrapper will help? Something like

Code: [Select]

#!/bin/sh
trap 'exit 0' SIGPIPE
exec /usr/bin/yes "$@" 2>/dev/null


[Rich]

Hi GNUser
You are welcome. Thanks for confirming it worked.

If you feel like satisfying my curiosity, what happens if you do this:

Code: [Select]

echo -e  "password\npassword\npassword" | bcrypt somefileI expect another  Broken pipe  message, but reality may differ from my expectations.

[GNUser]

Hi jazzbiker. No luck with the trap. But it's not surprising because with the exec statement, the script no longer exists in RAM when /usr/bin/yes executes.

So I also tried your suggestion without exec, like this:

Code: [Select]

#!/bin/sh
trap 'exit 0' SIGPIPE
/usr/bin/yes "$@" 2>/dev/null
But no luck with that, either.

Hi Rich. The superfluous passwords do not cause a Broken pipe message, surprisingly:

Code: [Select]

$ echo -e "tinycore\ntinycore\ntinycore\ntinycore\ntinycore\ntinycore" | bcrypt test.txt
Encryption key:
Again:
$
So the problem does not seem to be due to  yes  not knowing when to stop.

I'm happy with the wrapper script to fix the cosmetic issue when using  tce-load  and Rich's workaround for bcrypt. Thank you all

[jazzbiker]

Hi GNUser,

I see that the problem is solved, so maybe if it is still interesting for You and You have a spare minute You may try not use the wrapper for yes but try declaration of the SIGPIPE handler inside tce-load script.

Edit: maybe better to set ignore for the SIGPIPE:

Code: [Select]

trap '' SIGPIPE

Hi Rich. The superfluous passwords do not cause a Broken pipe message, surprisingly:

Code: [Select]

$ echo -e "tinycore\ntinycore\ntinycore\ntinycore\ntinycore\ntinycore" | bcrypt test.txt
Encryption key:
Again:
$


Probably the pipe is buffered and the string is small enough to be placed in the buffer as a whole.