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
