[Top][All Lists]

[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

> 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

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]