Allan Adler wrote:
> Allan Adler <[EMAIL PROTECTED]> 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/
--
http://mail.python.org/mailman/listinfo/python-list
