in spawned processes, both $$ and $PPID are wrong

2007-04-10 Thread skt
Bash does not represent current pid and parent process-id correctly
in spawned processes.

The configuration information below is from a RedHat 9.0 system,
but I have confirmed the problem still exists using
bash version 3.1.17(1)-release on Fedora Core 6.


Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib 
-D_GNU_SOURCE  -O2 -march=i386 -mcpu=i686 -g
uname output: Linux skywalker.ca.boeing.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 
2003 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]
The shell variables $$ and $PPID are not correct in child shell
processes spawned by a parent shell process.

Repeat-By:
[Describe the sequence of events that causes the problem
to occur.]
This script will demonstrate the problem:
-cut here--
#!/bin/sh
#
# 4/9/07 - Stan Tazuma
#
# demo of bash bugs in the use of:
#   $$  $PPID

demo1() {
echo function in forked process shows pid='$$' of original process,
echo not the new child process

echo demo1: pid=$$, PPID=$PPID
}

demo2() {
echo pipe situation -- the processes in the pipe should be able to
echo determine their own pid, but they cannot

some_var='some'

(echo demo2/pipe-writer: pid = $$, PPID = $PPID) |
(
read line
echo $line

# neither $$ nor $PPID appear to be evaluated at run-time,
# but are just kept as they were from the parent shell;
# since neither are environment variables, that is strange
echo demo2/pipe-reader: pid = $$, PPID = $PPID

# the next few lines show that other variables
# are being evaluated at run time
echo some_var=$some_var
some_var=something
echo some_var=$some_var
)
}


echo ==
echo parent pid = $$, PPID = $PPID
echo ==

echo calling demo1 in a background process ...
demo1 &
wait

echo ''
echo ==

echo calling demo2 ...
demo2

echo ''
echo ==
echo A situation where you need an accurate listing of pids:
echo You have a tree of processes for a system service, and you
echo want a reliable way of killing off all the processes started
echo for that service.  I would like to have each process write its
echo own pid to a pid file.
echo ''

-cut here--

Running the above script results in:

==
parent pid = 8291, PPID = 30730
==
calling demo1 in a background process ...
function in forked process shows pid=$$ of original process,
not the new child process
demo1: pid=8291, PPID=30730

==
calling demo2 ...
pipe situation -- the processes in the pipe should be able to
determine their own pid, but they cannot
demo2/pipe-writer: pid = 8291, PPID = 30730
demo2/pipe-reader: pid = 8291, PPID = 30730
some_var=some
some_var=something

==
A situation where you need an accurate listing of pids:
You have a tree of processes for a system service, and you
want a reliable way of killing off all the processes started
for that service. I would like to have each process write its
own pid to a pid file.





___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash


bug in bash handling of PS1 prompt

2005-06-22 Thread skt
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DSHELL -DHAVE_CONFIG_H  -I.  -I. -I./include -I./lib 
-D_GNU_SOURCE  -O2 -march=i386 -mcpu=i686 -g
uname output: Linux skywalker.ca.boeing.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 
2003 i686 i686 i386 GNU/Linux
Machine Type: i386-redhat-linux-gnu

Bash Version: 2.05b
Patch Level: 0
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

Not sure if this was meant as a bug or feature,
but I think it is a bug in bash.

When assigning to PS1 to change the prompt, bash
appears to append any new value to the initial default
value, rather than to replace it.   The human user
cannot see the original elements in the prompt.
Although not disturbing visually, bash sends a lot
of unnecessary characters out at each prompt.

If you use "script" or "expect" with logging
turned on, the log will show that each prompt
contains the original and new values of PS1.
Unsetting PS1 and then setting PS1 does not get
around the problem.  Changing PS1 does replace the
last PS1 assignment the user made, but does not
remove the initial value.

Repeat-By:

The bash session shown below was captured with "script",
and then post-processed with "cat -v", and shows the
bug in bash's handling of PS1.  The first prompt shown
below indicates that the PS1 set in the /etc/bashrc
file was added to the default prompt.
The "script" command was run on RedHat 9.0.

Stan Tazuma
Boeing
[EMAIL PROTECTED]


Script started on Wed 22 Jun 2005 02:51:50 PM PDT
^[]0;[EMAIL PROTECTED]:~/bugs/[EMAIL PROTECTED] bash-prompt]$ date^M
Wed Jun 22 14:51:53 PDT 2005^M
^[]0;[EMAIL PROTECTED]:~/bugs/[EMAIL PROTECTED] bash-prompt]$ echo 
$BASH_VERSION^M
2.05b.0(1)-release^M
^[]0;[EMAIL PROTECTED]:~/bugs/[EMAIL PROTECTED] bash-prompt]$ echo "$PS1"^M
[EMAIL PROTECTED] \W]\$ ^M
^[]0;[EMAIL PROTECTED]:~/bugs/[EMAIL PROTECTED] bash-prompt]$ PS1='hello> '^M
^[]0;[EMAIL PROTECTED]:~/bugs/bash-prompt^Ghello> date^M
Wed Jun 22 14:52:20 PDT 2005^M
^[]0;[EMAIL PROTECTED]:~/bugs/bash-prompt^Ghello> PS1=''^M
^[]0;[EMAIL PROTECTED]:~/bugs/bash-prompt^Gdate^M
Wed Jun 22 14:52:25 PDT 2005^M
^[]0;[EMAIL PROTECTED]:~/bugs/bash-prompt^G
Script done on Wed 22 Jun 2005 02:52:29 PM PDT


___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash