Re: Hightlighting in bash
On Thu, Mar 10, 2011 at 11:53:22AM -0800, Micah Cowan wrote: > > It wouldn't be difficult to write as a separate program, which is really > how this should be handled. You could redirect a pipeline's STDOUT and > STDERR to individual named pipes (FIFOs), and have a separate program > read from both pipes, inserting highlights around any data it copies > from the STDERR pipe. I cobbled up such a program (or pair of programs in the case) a while ago. It'd run stdin & stdout through a pty, and stderr through a seperate FIFO. I'd then run a shell within this environment. One thing I found wrt the version of bash being used was that it would not enable job control. It seems bash wanted stderr to be a pty as well, however a simple change removed that limitation in bash. .pdf
Job control in forced interactive mode upset if stderr is not the controlling tty
I have been playing with a terminal application which runs shells plumbed as below: fdwhat 0 pty slave 1 pty slave 2 some pipe To get the various shells being used to work, some of them require that '-i' be given for force interactive mode, fair enough. One problem though, bash job control is broken by the above. A job can be started in the background, and get suspended due to SIGTTIN; however the job cannot then be resumed. A simple example being: bash-3.2$ cat & [1] 25752 bash-3.2$ jobs [1]+ Stopped cat bash-3.2$ % cat bash: [25751: 1 255] tcsetattr: Invalid argument [1]+ Stopped cat bash: [25751: 1 255] tcsetattr: Invalid argument bash-3.2$ (I added the '255' debug to help track this down). I also noticed the versions of ksh and csh that I tested just worked. This would seem to be because ksh explicitly opened /dev/tty; and csh seemed to dup fd 0 (or maybe 1) to use for its interactive input. Looking at the open fds, I see that 255 is a dup of 2, and seems to be 'shell_tty' from jobs.c; a simple change to open /dev/tty fixes this. @@ -3479,7 +3480,9 @@ initialize_job_control (force) /* Get our controlling terminal. If job_control is set, or interactive is set, then this is an interactive shell no matter where fd 2 is directed. */ - shell_tty = dup (fileno (stderr)); /* fd 2 */ + shell_tty = open("/dev/tty", O_RDWR | O_NONBLOCK); + if (shell_tty == -1) +shell_tty = dup (fileno (stderr)); /* fd 2 */ shell_tty = move_to_high_fd (shell_tty, 1, -1); So - would there any reason why something like the above should not be applied? DF ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Job control in forced interactive mode upset if stderr is not the controlling tty
I have been playing with a terminal application which runs shells plumbed as below: fdwhat 0 pty slave 1 pty slave 2 some pipe To get the various shells being used to work, some of them require that '-i' be given for force interactive mode, fair enough. One problem though, bash job control is broken by the above. A job can be started in the background, and get suspended due to SIGTTIN; however the job cannot then be resumed. A simple example being: bash-3.2$ cat & [1] 25752 bash-3.2$ jobs [1]+ Stopped cat bash-3.2$ % cat bash: [25751: 1 255] tcsetattr: Invalid argument [1]+ Stopped cat bash: [25751: 1 255] tcsetattr: Invalid argument bash-3.2$ (I added the '255' debug to help track this down). I also noticed the versions of ksh and csh that I tested just worked. This would seem to be because ksh explicitly opened /dev/tty; and csh seemed to dup fd 0 (or maybe 1) to use for its interactive input. Looking at the open fds, I see that 255 is a dup of 2, and seems to be 'shell_tty' from jobs.c; a simple change to open /dev/tty fixes this. @@ -3479,7 +3480,9 @@ initialize_job_control (force) /* Get our controlling terminal. If job_control is set, or interactive is set, then this is an interactive shell no matter where fd 2 is directed. */ - shell_tty = dup (fileno (stderr)); /* fd 2 */ + shell_tty = open("/dev/tty", O_RDWR | O_NONBLOCK); + if (shell_tty == -1) +shell_tty = dup (fileno (stderr)); /* fd 2 */ shell_tty = move_to_high_fd (shell_tty, 1, -1); So - would there any reason why something like the above should not be applied? DF ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: SIGTTOU handling
On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > Can someone provide a hint to this end? My deepest > thanks for your time and any advice you might be > able to provide. I get exactly that behaviour with a program I have been working on. I traced it to the fact that I ran bash with stderr not attached to a tty. I could 'fix' it by either duping stderr to stdout, or patching bash to not worry about stderr not being a terminal. Since I actually wanted to seperate the stdout and stderr output of the shell and child processes, I ended up patching bash. I don't know if this is your issue. DF
Re: SIGTTOU handling
On Mon, Nov 12, 2007 at 08:03:38PM +, Derek Fawcus wrote: > On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > > Can someone provide a hint to this end? My deepest > > thanks for your time and any advice you might be > > able to provide. > > I get exactly that behaviour with a program I have been working on. Oops - not exactly the same (bad memory) - just very similar. I was getting a failure in tcsetattr (I think) on trying to resume a job. So probably not the same cause. DF
Re: SIGTTOU handling
On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > > I had some difficulties getting job control working at > first. I found that having the child process do a > setpgrp() before forking to the bash instance made the > error message about disabling job control go away. Try setsid() instead.
Re: Prefer non-gender specific pronouns
On Sun, Jun 06, 2021 at 05:00:21PM +0300, Ilkka Virta wrote: > On Sun, Jun 6, 2021 at 2:49 PM Léa Gris wrote: > > For the second person, there's of course "thou", but for some reason, > I've never heard anyone suggest using that in practice. Hast thou never been to Yorkshire or Lancashire? :-) One can still occasionally experience thee/thy/thou/thine in all their glory. Some of us could cope with 'thou art' rather than 'you are', but it does tend to feel a bit archaic. DF