+15
−18
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The patch fixes a few corner cases around tty line editing with very long input lines: - n_tty_receive_char(): don't simply drop eol characters, otherwise canon_data isn't increased and the reader isn't woken up. - n_tty_receive_room(): If there is no newline pending and the edit buffer is full, allow only a single character to be written (until eol is found and the line is flushed), so characters from the next line aren't dropped. - write_chan(): if an incomplete line was written, continue writing until write() returns 0, otherwise it might not write the eol character to flush the line and the writer goes to sleep without ever being woken up. BTW the core problem is that part of this should be handled in the receive_buf path, but for this it has to return the number of written characters, as the amount of written characters may not be the same as the amount of characters going into the write buffer, so the receive_room() usage in pty_write() is not really reliable. Alan said: The problem looks valid. The behaviour of 'traditional unix' appears to be the following If you exceed the line limit then beep and drop the character Always allow EOL to complete a canonical line input Always do signal/control processing if enabled Signed-off-by:Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
CRA Git | Maintained and supported by SUSTech CRA and CCSE