Tiny Core Extensions > TCE Bugs

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

<< < (4/8) > >>

GNUser:
Hi jazzbiker. yes-related "Broken pipe" messages still appear if I add this to /usr/bin/tce-load:

--- Code: ---trap '' SIGPIPE
--- End code ---
I have submitted a bug report to the havoc developer.

GNUser:
Hi Juanito. havoc developer says the pipe of interest is created by the shell, not the terminal emulator (see here). Moving blame from terminal emulator to shell helps explain why havoc and weston-terminal are both affected.

I use havoc + busybox ash 99.9% of the time. I tried havoc + bash as a test and problem did not go away.

Since all terminal emulators and shells seem to be affected, I think the problem may have something to do with how weston or labwc is being started. Can you suggest a way to start the graphical session different from this (which is what weston.tcz.info suggests):

--- Code: ---sudo -- seatd -g staff -n /run/seatd.sock & XDG_RUNTIME_DIR=/run/user/$(id -u) weston

--- End code ---
?

jazzbiker:
Hi!

I've made some experiments trying to reproduce the observed by GNUser behaviour of yes. As it was described in the link by patrikg it looks rather counterintuitive.
I'm testing in TC14 x86 under Xorg.


--- Code: ---tc@box:~$ yes | lua -e 'print(io.read())'
y
tc@box:~$ yes no | lua -e 'print(io.read())'
no
tc@box:~$ trap '' SIGPIPE # ignore signal
tc@box:~$ yes | lua -e 'print(io.read())'
y
yes: Broken pipe
tc@box:~$ yes no | lua -e 'print(io.read())'
no

--- End code ---
here the pipeline hangs, interrupted by Ctrl-C

--- Code: ---^Ctc@box:~$  trap - SIGPIPE # restore default handler
tc@box:~$ yes | lua -e 'print(io.read())'
y
tc@box:~$ yes no | lua -e 'print(io.read())'
no
tc@box:~$

--- End code ---

So looks like havoc envokes the shell with SIGPIPE ignored. The cure may be restoring the default handler.

@GNUser, You may try adding

--- Code: ---trap - SIGPIPE
--- End code ---
to tce-load or to yes wrapper.

Looks like it is havoc's fail cause it leaves the shell without the SIGPIPE handler. I can't guess why the same behaviour is exhibited by another wayland terminal emulator, looks like coincidence.

You can notice the changes in the yes behaviour when it is supplied with the output string.

jazzbiker:

--- Quote from: jazzbiker on October 28, 2023, 04:00:50 PM ---You can notice the changes in the yes behaviour when it is supplied with the output string.

--- End quote ---

In fact the difference in the yes behaviour is between single-char and multi-char output:

--- Code: ---tc@box:~$ trap '' SIGPIPE
tc@box:~$ yes | lua -e 'print(io.read())'
y
yes: Broken pipe
tc@box:~$ yes n | lua -e 'print(io.read())'
n
yes: Broken pipe
tc@box:~$ yes no | lua -e 'print(io.read())'
no
^Ctc@box:~$ # hung up and interrupted by Ctrl-C

--- End code ---

Rich:
Hi jazzbiker
Nice find. Works under TC10 x86 too:

--- Code: ---tc@E310:~$ busybox yes | head -n 3
y
y
y
tc@E310:~$ trap '' SIGPIPE
tc@E310:~$ busybox yes | head -n 3
y
y
y
yes: Broken pipe
tc@E310:~$ trap - SIGPIPE
tc@E310:~$ busybox yes | head -n 3
y
y
y
tc@E310:~$
--- End code ---


--- Quote from: jazzbiker on October 28, 2023, 04:00:50 PM --- ... Looks like it is havoc's fail cause it leaves the shell without the SIGPIPE handler. I can't guess why the same behaviour is exhibited by another wayland terminal emulator, looks like coincidence. ...
--- End quote ---
Maybe they share a common code base. That can happen when
someone forks a program to implement changes they want.

Or maybe it's being caused by something else they share in
common, Wayland itself.

Navigation

[0] Message Index

[#] Next page

[*] Previous page