Re: bash: no job control in this shell
Chet Ramey wrote: > > 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. >>> >>> But when the initial output from bash comes to my applet, it says "bash: >>> no >>> job control in this shell". > >>In general, this happens when bash thinks it's interactive but can't >>obtain a handle to the controlling terminal that allows it to manipulate >>the controlling terminal's process group. Since that's all job control >>really is -- switching the terminal's process group between processes -- >>bash turns off job control if it's not available. > >>Other programs that attempt to put the terminal into "raw" mode usually >>do it by trying to open "/dev/tty" (always the controlling terminal) and >>change its attributes. If that fails, they fall back to line-at-a-time >>mode. > > I was reading up more on pseudo-terminals > (https://www.linux.org/docs/ldp/howto/Text-Terminal-HOWTO-7.html) and it > mentioned checking which tty is attached to which process, so in my applet > I did a ps -eaf | grep bash and the bash my applet code starts up has > pts/11 (the same tty the bash where I start the applet program has) and I > did tty in the applet and it returned /dev/pts/8 which matches up with the > slave name openpty() returns. > > I had also noticed that when I try to use 'less' in the applet, that I > can't get out, so when I Ctrl-C to kill my code in the bash shell I > started my applet from, the bash command line is now messed up. so I am > *guessing* even tho the "applet" bash tty returns /dev/pts/8, when in > that applet bash I run the less command it is changing the attributes of > pts/11, so the interaction in the "applet" bash is not set up as it should > be, and my real bash window is now messed up ... plausible ? > > And if that is plausible, I guess the next question is there any way to > use the slave name/tty to associate with the bash when I run it from my > applet ...? > > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > Live Strong. No day but today. > Chet Ramey, ITS, CWRU[EMAIL PROTECTED] > http://cnswww.cns.cwru.edu/~chet/ > > > ___ > Bug-bash mailing list > Bug-bash@gnu.org > http://lists.gnu.org/mailman/listinfo/bug-bash > > -- View this message in context: http://www.nabble.com/bash%3A-no-job-control-in-this-shell-tf3995540.html#a11524074 Sent from the Gnu - Bash mailing list archive at Nabble.com. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
printf '\x' exit status is 0
(on my debian system, bashbug reports for bash 2.05) printf status is 0 but /usr/bin/printf is 1. Is this the expected behavior? [EMAIL PROTECTED]:~$ bash3 [EMAIL PROTECTED]:~$ bash3 --version GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. [EMAIL PROTECTED]:~$ printf '\x' bash3: printf: missing hex digit for \x [EMAIL PROTECTED]:~$ echo $? 0 [EMAIL PROTECTED]:~$ /usr/bin/printf '\x' /usr/bin/printf: missing hexadecimal number in escape [EMAIL PROTECTED]:~$ echo $? 1 -- Poor Yorick ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash: no job control in this shell
JimK wrote: >> I was reading up more on pseudo-terminals >> (https://www.linux.org/docs/ldp/howto/Text-Terminal-HOWTO-7.html) and it >> mentioned checking which tty is attached to which process, so in my applet >> I did a ps -eaf | grep bash and the bash my applet code starts up has >> pts/11 (the same tty the bash where I start the applet program has) and I >> did tty in the applet and it returned /dev/pts/8 which matches up with the >> slave name openpty() returns. >> >> I had also noticed that when I try to use 'less' in the applet, that I >> can't get out, so when I Ctrl-C to kill my code in the bash shell I >> started my applet from, the bash command line is now messed up. so I am >> *guessing* even tho the "applet" bash tty returns /dev/pts/8, when in >> that applet bash I run the less command it is changing the attributes of >> pts/11, so the interaction in the "applet" bash is not set up as it should >> be, and my real bash window is now messed up ... plausible ? >> >> And if that is plausible, I guess the next question is there any way to >> use the slave name/tty to associate with the bash when I run it from my >> applet ...? You might want to look at examples/rlfe in the readline distribution. It does the same sort of front-end pty manipulation you;re interested in. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: printf '\x' exit status is 0
Poor Yorick wrote: > (on my debian system, bashbug reports for bash 2.05) Is that a Sarge system? Note that Etch is now the Debian Stable release. However that won't change the results from the problem that you are have reported. > printf status is 0 but /usr/bin/printf is 1. Is this the expected behavior? On a Sarge system: $ type printf printf is a shell builtin $ /usr/bin/printf --version printf (GNU coreutils) 5.2.1 This indicates that those are different printf implementations. > [EMAIL PROTECTED]:~$ bash3 > [EMAIL PROTECTED]:~$ bash3 --version > GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) > Copyright (C) 2004 Free Software Foundation, Inc. > [EMAIL PROTECTED]:~$ printf '\x' > bash3: printf: missing hex digit for \x > [EMAIL PROTECTED]:~$ echo $? > 0 That appears to be a bug to me. Because printf failed it should return a non-zero exit code. I just checked the current 3.2 patch 17 and see no change in that behavior. > [EMAIL PROTECTED]:~$ /usr/bin/printf '\x' > /usr/bin/printf: missing hexadecimal number in escape > [EMAIL PROTECTED]:~$ echo $? > 1 This appears to be the correct behavior. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash strangeness with utf-8
Joe Peterson wrote: > Benno Schulenberg wrote: > > On what terminal are you doing this? To what encoding is the > > terminal set? > > Mainly xterm (version 225, at least in one case). And I have the > utf8 option on. Does this set the encoding to the proper value, > or do I need more? No idea, I use Konsole. Better read man xterm. > But also, I have tried this in the simple virtual terminal > (ctrl-alt-f1, etc.), which also exhibits the problem. Okay. So what says a typescript in a blank shell with only LANG defined? Does the ^[[1034h still get printed before the prompt? Benno ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash strangeness with utf-8
Benno Schulenberg wrote: > No idea, I use Konsole. Better read man xterm. The strangeness happens in Konsole too (as well as the virtual terminals), so I kind of doubt it's the term's issue... > Okay. So what says a typescript in a blank shell with only LANG > defined? Does the ^[[1034h still get printed before the prompt? In this case, no ^[[1034h, but the utf glitch still happens. Could it have something to do with bash miscalculating the size of the characters? Strange thing is that I am not using any non-ASCII chars in my commands, of course, so not sure why that would matter. Is there a way to turn off bash's handling of UTF, so when I set LANG, it will not do anything "different"? This could provide clues. Thanks, Joe ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: printf '\x' exit status is 0
Poor Yorick wrote: > (on my debian system, bashbug reports for bash 2.05) > > printf status is 0 but /usr/bin/printf is 1. Is this the expected behavior? > > [EMAIL PROTECTED]:~$ bash3 > [EMAIL PROTECTED]:~$ bash3 --version > GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) > Copyright (C) 2004 Free Software Foundation, Inc. > [EMAIL PROTECTED]:~$ printf '\x' > bash3: printf: missing hex digit for \x > [EMAIL PROTECTED]:~$ echo $? > 0 Bash treats unrecognized backslash escapes as characters to be printed and does not consider them an error. \x without any hex digits doesn't have any special meaning, though, since it's probably not what's intended, bash prints a warning. Chet > [EMAIL PROTECTED]:~$ /usr/bin/printf '\x' > /usr/bin/printf: missing hexadecimal number in escape > [EMAIL PROTECTED]:~$ echo $? > 1 > -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
