Oleg Nesterov has distilled a very simple (and reproducable) testcase
below for what appears to be a potential long-existing bash bug. This is
a problem that triggers on Linux quite frequently. (i can also send the
configs.tar.bz2 testcase i made - but i think Oleg's is far simpler) I
used bas
Vincent Lefevre wrote:
> which can be interpreted as being the remote shell daemon. I think
> that the bash man page should be clarified.
I'll tighten it up some.
> My main complaint is that bash behaves differently when one uses
> "ssh " and "ssh -t ". Something needs to
> be done to make the
I'm using netcat to listen for Avaya phone system call logs.
Thanks for the advice. I'll check that out and see if it could be
something that I might use.
Bob Proulx wrote:
Jesse Molina wrote:
Netcat has strange issues about wanting stdin -- it won't run
backgrounded without being fed ta
Jesse Molina wrote:
> Netcat has strange issues about wanting stdin -- it won't run
> backgrounded without being fed tail -f /dev/null. I wonder if it
> isn't the problem here. I had discounted it since I redirected both
> stdin and stdout to the logfile.
I have had problems with netcat before.
Hmmm...
I'm using 'lsof -d 0-255' and I don't see any FDs related to the subshell, the
tail, or the NETCAT processes.
I don't know what this shell is waiting on, though I'm sure it's one of these
processes. As soon as I kill them off, the shell releases.
I want to go back to the fact tha
Jesse Molina <[EMAIL PROTECTED]> writes:
> Netcat has strange issues about wanting stdin -- it won't run backgrounded
> without being fed tail -f /dev/null. I wonder if it isn't the problem here.
> I had discounted it since I redirected both stdin and stdout to the logfile.
What's wrong with
Thank you for the explanation about the descriptors. That's very insightful.
However, your suggested fix did not help the situation. I think that was even
something that I had tried the day before.
Netcat has strange issues about wanting stdin -- it won't run backgrounded
without being fed t
On 2007-12-05 14:31:33 -0500, Chet Ramey wrote:
> No. sshd is not the `remote shell daemon'. The remote shell daemon
> the man page speaks of runs on port 514 and is named either `rshd'
> or `remshd'.
The sshd man page says:
sshd (OpenSSH Daemon) is the daemon program for ssh(1). Together
Jesse Molina <[EMAIL PROTECTED]> wrote:
> Basically, on the two troubled systems, my interactive shell will
> hang after I've disowned a process. On one other system, everything
> works as expected. I expect that a disowned process should not hang
> logout -- disowned means disowned.
The termina
Hi!
I am having a problem on two Linux systems and then not on two others.
Slightly differnt OS and bash in each case. I'm puzzled.
Basically, on the two troubled systems, my interactive shell will hang after
I've disowned a process. On one other system, everything works as expected. I
ex
Vincent Lefevre wrote:
> On 2007-12-04 22:56:21 -0500, Chet Ramey wrote:
>> Bash does 1 if (and only if) it can detect it's being run with its
>> stdin connected to a socket. `ssh -t' intentionally defeats that.
>> There is other checking that SSH_SOURCE_BASHRC enables: looking for
>> SSH_CLIENT o
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKA
On 2007-12-04 22:56:21 -0500, Chet Ramey wrote:
> Bash does 1 if (and only if) it can detect it's being run with its
> stdin connected to a socket. `ssh -t' intentionally defeats that.
> There is other checking that SSH_SOURCE_BASHRC enables: looking for
> SSH_CLIENT or SSH2_CLIENT.
So, will SSH_
13 matches
Mail list logo
