anaconda.real in RH7.1

Steve Holden steve at holdenweb.com
Wed Sep 7 19:02:38 CEST 2005


Allan Adler wrote:
> Allan Adler <ara at nestle.csail.mit.edu> writes:
> 
> 
>>I'm trying to reinstall RedHat 7.1 Linux on a PC that was disabled when
>>I tried to upgrade from RH7.1 [....] 
>>The file anaconda.real is invoked with the line
>>exec /usr/bin/anaconda.real -T "$@"
>>I don't know what effect the -T "$@" has.
> 
> 
> Tiny progress on this: in a shell script, "$@" apparently lets you refer
> to the output of a previous command. I don't know what output would be
> relevant, since the last few lines of the shell script anaconda that
> invokes anaconda.real are:
> 
> cd /usr/sbin
> uncpio < sbin.cgz
> rm sbin.cgz
> cd /lib
> uncpio < libs.cgz
> rm libs.cgz
> cd /
> exec /usr/bin/anaconda.real -T "$@"
> 
$@ doesn't refer to the output of a previous command. It refers to a 
list of quoted arguments of the script it's a part of. It's supposed, 
IIRC, to be equivalent to

     exec /usr/bin/anaconda.real -T "$1" "$2" "$2" ...

as opposed to $*, which would be equivalent to

     exec /usr/bin/anaconda.real -T $1 $2 $3 ...

> As for exec itself, the command line
> exec -T
> leads to a complaint that -T is an illegal option for exec, while
> python -T
> leads to a usage statement that doesn't list -T among the options for python.
> So, I still don't understand the statement that is used to call the python
> script anaconda.real.
> 
What's supposed to happen is that anaconda.real is supposed to be 
processed by the Python interpreter. You will probably find a "shebang" 
line at the start of anaconda.real that reads something like

#!/usr/bin/python1.5.2

The -T argument is, I suspect, intended for anaconda.real - you could 
check the source and verify that it looks at sys.argv.

> I also tried to execute in interactive session some of the commands in the
> file anaconda.real. E.g. the first command signal.signal(SIGINT,SIG_DFL)
> 
> Python 1.5.2 (#1, Mar  3 2001, 01:35:43)
> [GCC 2.96 20000731 (Red Hat Linux 7.1 2 on linux-i386
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> 
>>>>signal.signal(SIGINT,SIG_DFL)
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> NameError: signal
> 
>>>>import signal
>>>>signal.signal(SIGINT,SIG_DFL)
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> NameError: SIGINT
> 
>>>>import SIGINT
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: No module named SIGINT
> 
> On the other hand, while looking at Kernighan and Pike, "The Unix programming
> environment" (1984), I fortuitously ran across a discussion of signals and
> interrupts on p.225, including the example
> 
> #include <signal.h>
> signal(SIGINT,SIG_DFL)
> 
> which restores default action for process termination. The resemblance to the
> first command in anaconda.real is so close that I think the intention in
> both must be the same. What is the right way to get python to do this?
> 
SIGINT is defined in the signal module so you probably want

     signal.signal(signal.SIGINT, signal.SIG_DFL)

> The file anaconda.real doesn't explicitly execute
> import signal
> but it still somehow knows what signal means (my example session above shows
> that it stops complaining about not knowing what signal means after I import
> signal). Presumably there is some way of invoking python that causes signal
> and other stuff to be imported automatically. What is it?

On that one you have me stumped. It's possible it imports some other 
module that plays with the namespace in a magical way.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/




More information about the Python-list mailing list