Re: A background ssh can take over the tty from bash?

On Tue, Jun 13, 2017 at 11:00 AM, L A Walsh wrote: > >In this case you need to use "-n" with "-f" OR not use > either if you wish it to be suspended. > I did want the `ssh -o ControlMaster=yes` to run as a daemon. >If I launch ssh without "-f" but put it in background, it doesn't > gra

Re: A background ssh can take over the tty from bash?

Clark Wang wrote: On Tue, Jun 13, 2017 at 2:48 AM, L A Walsh wrote: Clark Wang wrote: I've checked the ssh process and it does not catch SIGTTIN and that's why I'm confused. From what I understand, a background process will automatically block when it tries to rea

Re: A background ssh can take over the tty from bash?

On Tue, Jun 13, 2017 at 2:48 AM, L A Walsh wrote: > Clark Wang wrote: > >> >> I've checked the ssh process and it does not catch SIGTTIN and that's why >> I'm confused. >> >> > >From what I understand, a background process will automatically > block when it tries to read from STDIN. By

Re: Buffer corruption when the terminal is resized.

Well, I seriously have no idea what approach would be the right one to fix this but I've responded on the other side and this was Egmont Koblinger (vte developer) response: Yes, indeed, rewrapping the contents on resize breaks this assumption. Given that in a(n obviously non-representative)

Re: Trailing newlines disappear

On 13/06/2560 02:54, Chet Ramey wrote: > If you want to effectively change it to a newline, specify NUL as the > line delimiter using the -d option (new in bash-4.4). Thanks, that sounds like a clean solution! I only reverted to mapfile because $(...) command substitution could not be made to work

Re: Buffer corruption when the terminal is resized.

On 6/12/17 4:24 PM, Chet Ramey wrote: > On 6/12/17 4:08 PM, Paul Peet wrote: >> Is there a flag in macOS's Terminal? It's because I am also >> experiencing this bug on macOS's Terminal :) (with bash). > > I doubt it. My testing wasn't very scientific. I just opened up a new > Terminal, ran bash-4.

Re: Buffer corruption when the terminal is resized.

On 6/12/17 4:08 PM, Paul Peet wrote: > Is there a flag in macOS's Terminal? It's because I am also > experiencing this bug on macOS's Terminal :) (with bash). I doubt it. My testing wasn't very scientific. I just opened up a new Terminal, ran bash-4.4, typed a bunch of characters, and constantly r

Re: Buffer corruption when the terminal is resized.

Is there a flag in macOS's Terminal? It's because I am also experiencing this bug on macOS's Terminal :) (with bash). On Mon, Jun 12, 2017 at 9:47 PM, Chet Ramey wrote: > On 6/12/17 3:45 PM, Paul Peet wrote: >> Well, I can try to re-open this issue on the gnome-terminal/vte3 side. >> Perhaps I ca

Re: Trailing newlines disappear

On 6/9/17 1:40 PM, Peter & Kelly Passchier wrote: > On 09/06/2560 23:38, L A Walsh wrote: >> Chet Ramey wrote: >>> >>> Should mapfile silently drop the NULs? >> >> Maybe add a flag to ignore NUL bytes that could be used in the 'read' >> statement as well? If not specified, keep same behavior? >

Re: Buffer corruption when the terminal is resized.

On 6/12/17 3:45 PM, Paul Peet wrote: > Well, I can try to re-open this issue on the gnome-terminal/vte3 side. > Perhaps I can convince them to take an approach where the terminal > isn't violating the assumptions of the display engine by introducing a > new flag or something like that. Maybe. I kn

Re: Buffer corruption when the terminal is resized.

Well, I can try to re-open this issue on the gnome-terminal/vte3 side. Perhaps I can convince them to take an approach where the terminal isn't violating the assumptions of the display engine by introducing a new flag or something like that. On Mon, Jun 12, 2017 at 9:27 PM, Chet Ramey wrote: > On

Re: Buffer corruption when the terminal is resized.

On 6/12/17 2:24 PM, Paul Peet wrote: > I guess this is why I don't get the garbage output with gnome-terminal > and dash. Dash doesn't use readline apparently. Dash doesn't support line editing at all out of the box, though you can build it using libedit. > > So, what can be done to actually fix

Re: A background ssh can take over the tty from bash?

Clark Wang wrote: I've checked the ssh process and it does not catch SIGTTIN and that's why I'm confused. From what I understand, a background process will automatically block when it tries to read from STDIN. By definition, processes become bg-processes by using '&'. I haven't loo

Re: Buffer corruption when the terminal is resized.

I guess this is why I don't get the garbage output with gnome-terminal and dash. Dash doesn't use readline apparently. So, what can be done to actually fix this? On Mon, Jun 12, 2017 at 7:55 PM, Chet Ramey wrote: > On 6/12/17 1:38 PM, Paul Peet wrote: >> Uhmm, I am not sure how to interpret thes

Re: Buffer corruption when the terminal is resized.

On 6/12/17 1:38 PM, Paul Peet wrote: > Uhmm, I am not sure how to interpret these results (All shells or > terminals have been tested with Ubuntu 17.04): > > gnome-terminal + bash: Happens > gnome-terminal + zsh: This bug also happens here, lines are getting > removed/repeated... > gnome-terminal

Re: Buffer corruption when the terminal is resized.

Uhmm, I am not sure how to interpret these results (All shells or terminals have been tested with Ubuntu 17.04): gnome-terminal + bash: Happens gnome-terminal + zsh: This bug also happens here, lines are getting removed/repeated... gnome-terminal + dash: Does not happen. (I changed the PS1="userna

Re: A background ssh can take over the tty from bash?

On 6/12/17 12:16 PM, Clark Wang wrote: > Since ssh has a handle on its controlling terminal, it must do something > that allows it to read from it even if it's not in the foreground process > group. In any event, -n is the way to deal with that. > > > Thanks Chet. > > I reposted the

Re: A background ssh can take over the tty from bash?

On Mon, Jun 12, 2017 at 10:48 PM, Chet Ramey wrote: > > > > This has come up before. You need to use `ssh -n' to avoid it > reading from > > stdin. Processes can ignore SIGTTIN, and ssh does so to avoid being > stopped > > if it reads from the tty while in the background. > > > > > >

Re: Multiline commands do not survive history -w/-r

On 6/11/17 9:00 PM, gaze...@xmission.com wrote: > Bash Version: 4.3 > Patch Level: 48 > Release Status: release > > Description: > Multiline commands (i.e., a command with embedded newlines) do not > survive > intact when written out to the history file and then reloaded. Yes, the h

Re: A background ssh can take over the tty from bash?

On 6/11/17 10:24 PM, Clark Wang wrote: > On Mon, Jun 12, 2017 at 5:48 AM, Chet Ramey > wrote: > > On 6/10/17 10:19 AM, Clark Wang wrote: > > > If I kill the "ssh -o ControlMaster=no -o ControlPath=/tmp/socket.tmp > > 127.0.0.1 sleep " then tty #1 (pts/