3 ms·
One thing that I don't rn see is why when I have: printf(">"); read(0, ...); I can only delete (DEL) chars that I've written, but not the ">". Who takes
by int0x80 9y ago
One thing that I don't rn see is why when I have:
printf(">");
read(0, ...);
I can only delete (DEL) chars that I've written, but not the ">". Who takes care of that, given that is not using readline?
I guess it has to be the N_TTY line disc but I'm not sure how it works given that I can manually place the cursor where ever I want differently.
- jclulow 9y agoThe line discipline in most UNIX-like kernels is generally pretty simple, and mostly open-loop. In cooked mode, the kernel is just accumulating bytes in an edit buffer; if you add one, it echoes it; if you remove one, it probably emits "\b \b". If the buffer is empty and you press delete, it does nothing. If you were to send cursor positioning sequences, instead of just ">", this would probably fall apart as the kernel's edit buffer and the terminal reality would be out of sync.
- int0x80 9y agoThanks, it makes sense now. So with every `read' to the tty it starts a new edit buffer, I pressume?
- Tyr42 9y agoNo I don't think it's the "Read" call, but rather your program doesn't see any input in stdin until an enter is pressed. (In cooked mode).
- int0x80 9y agoI think I didn't explain myself. What you say is true, but even if your program doesn't see any input, you can (the kernel n_tty line discipline) edit the input (delete it). So if I do print() read() print() read() the reads will only be able to edit what has been input since that particular syscall.