[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash: no job control in this shell
From: |
Bob Proulx |
Subject: |
Re: bash: no job control in this shell |
Date: |
Thu, 28 Jun 2007 14:33:10 -0600 |
User-agent: |
Mutt/1.5.9i |
JimK wrote:
> I have written a java applet to interact with bash in the background to let
> the applet user interact just like they were using bash itself.
Does this java applet set up a master-slave pty for bash's input and
output? This is what the 'expect' program and similar usually do.
> But when the initial output from bash comes to my applet, it says "bash: no
> job control in this shell".
When bash starts up it inspects the stdin (IIRC) and determines that
it either is or is not a tty device. If a tty then it assumes it is
running interactively. If not a tty then it behaves in a batch mode.
I did not remember bash using this to enable/disable job control but
bash does use this to affect an 'interactive' mode enabled/disabled
and that does have other effects such as printing of prompts and other
things.
> Which initially I didn't think really mattered, but I just found out that
> man/less/more do not work after displaying their initial screen. Commands
> like "q" are not processed like they should so you are stuck inside of
> man/less/more.
You would probably need "q\n" in order to get the data flushed to the
subprocess. This is probably a stdio buffering issue. When the stdio
library determines that the output is not a tty then the output is
buffered into large blocks for performance reasons. If the output is
a tty then buffering is disabled. (I can't remember if buffering is
off or line buffered when the output is a tty.)
> So I am wondering if it is because I do not have any job control in my
> shell.
No. But it is related to the same reason that job control is not
enabled.
> So, I am trying to find out why my bash has no job control and how I can
> address that to see if that is why man/less/more do not work.
Because pagers routinely place the tty into raw mode and also control
the full screen they usually expect a full terminal environment
including tty and terminal emulation. When this is not available they
fall back into a line oriented operating mode.
When the tty driver is in the standard canonical mode a newline is
usually required to enter data. If no tty driver is present then it
won't be used and can't be placed into a raw mode. Then standard
program buffering rules apply.
> Appreciate any insights as to why bash is deciding it has no job control or
> how I might find out why it is saying that ..
Look at the 'expect' program as one example well known for handling
subprocesses in this way.
Bob