2006/2/3, Nick Pilon <[EMAIL PROTECTED]>:
> On 2/3/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> > Wait can make a parent wait for a child, I need a way for a child to
> > stop until the parent gives up control of the terminal and puts the
> > child in it's own process group. Actually, a child can do both these
> > things itself and just ignore the parent, but I seem to remember some
> > kind of problem when setting up a pipeline when the first command
> > would exit before the parent forks the second command, this would
> > cause occasional (very rare) strangeness.
>
> This is before the child exec()s, right? Well, presumably some method
> of IPC could be used by the shell to tell the child that it's ready to
> go, but I don't know if any are cheap enough.
A sommon signal would be cheaper than the behaviour we are seeing on
OS X, but there really should be a better solution.
>
> If it is sleep(), I don't see why the behaviour would be present in
> 1.20.0 and 1.20.2, but go away in 1.20.1. OS X hasn't changed, the way
> fish is calling sleep hasn't changed (right?) so why should it behave
> differently?
The sleep call didn't change, but I think that 1.20.1 (correctly)
marked the prompt command as non-interactive and therefore didn't put
it under job control. The 1.20.2 version you tried out incorrectly
marked the prompt command as interactive, with all that implies w.r.t.
job control, sleep() calls, etc. But I've been thinking about the
whole sleep() problem, and it's the wrong solution. Since only
interactive jobs ever sleep, any bugs avoided through this behaviour
still exist when job control is disabled, i.e. in non-interactive
mode. I'll simply set the process group, steal the terminal, try to
locate the problem and deal with it in some other way. Unfortunatly, I
don't actually remember what exactly triggered the problem...
>
> My intuition is more inclined to blame something relating to the OS X
> sed command. Because you changed something in the handling for that
> between 1.20.0 and 1.20.1, and it worked. And now 1.20.2 uses more sed
> calls when building the prompt, and something has gone all weird
> again.
I belive 1.20.2 calls sed one time less than 1.20.1, so that's not
enough in itself. But the prompt changes might still be to blame. You
can test this theory by using the 1.20.1 prompt with the 1.20.2
binary.
>
> > Does it not find the gettext _command_ or the gettext C function? IS
> > the former in your PATH?
>
> I'm fairly certain it's the gettext command, as it complains about
> line 85 of /usr/local/etc/fish, which calls the gettext command. I'm
> not sure if it's in my PATH at that point. The only gettexts on my
> system are installed by fink/darwinports, so they're not in the
> "usual" places. (They're in /sw/bin and /opt/local/bin) But then why
> would 1.20.1 find it and 1.20.2 not?
Ok, I checked the source, and I'd created a bad conditional statement.
Fish can't find the gettext command but still tries to use it. Should
be fixed.
I've also added a check to make sure /sw/bin is in PATH if it exists.
>
> (Also, we may want to consider no longer Cc-ing Sean, as this has
> moved a little ways away from his original problem.)
True. Done.
>
> --
> -Nick Pilon
>
--
Axel
N�HY隊X���'���u���[�������
ަ�k��!�� �W�~�鮆�zk��C� [EMAIL PROTECTED],���� a{�
��,�H��4�m�����Z�� jY�w��ǥrg
