1 |
On Dec 23, 2010, at 8:10 AM, Fabian Groffen wrote: |
2 |
|
3 |
> On 23-12-2010 08:08:28 -0600, Perry Smith wrote: |
4 |
>>> I've not seen such problems since I do </dev/null. |
5 |
>>> Does it help to redirect stdin from /dev/null for you too? |
6 |
>> |
7 |
>> I'm not sure when you are suggesting to do the redirect. It would cause the stty to fail and the read |
8 |
>> would return immediately so it would avoid hanging forever. |
9 |
>> |
10 |
>> I've never seen this before (a configure script that pauses or expects input). Given that Portage is a 'batch' type |
11 |
>> concept, maybe the redirect should be part of Portage. |
12 |
> |
13 |
> It should be IIRC, based on FEATURES=interactive. Anyway, if /bin/sh is |
14 |
> an issue on AIX, perhaps we better run their configure script with |
15 |
> Prefix'/bootstrap's bash instead? |
16 |
|
17 |
|
18 |
Seems like to get any type of wide spread stability between platforms and |
19 |
releases, you would want to use as few native elements as possible. So, |
20 |
using a bash that you have control over seems wise in the long term. The |
21 |
question is if this config script uses anything in ksh that isn't in bash. I would |
22 |
assume not since many /bin/sh's point to bash on other platforms (mac for |
23 |
example). |
24 |
|
25 |
The other thing is to be sure that the shell knows that it is running a script |
26 |
and is not interactive. If you passed bash the wrong flag, I bet it would |
27 |
make the same mistake and read input in raw mode so that the user could |
28 |
do command line editing (which you don't want in this case). |
29 |
|
30 |
pedz |