From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: FPATH/autoload still strange in -dev-21
Date: Thu, 6 Apr 2000 09:51:41 +0000 [thread overview]
Message-ID: <1000406095141.ZM15654@candle.brasslantern.com> (raw)
In-Reply-To: <200004060818.KAA06319@beta.informatik.hu-berlin.de>
On Apr 6, 10:18am, Sven Wischnowsky wrote:
} Subject: Re: FPATH/autoload still strange in -dev-21
}
} Bart Schaefer wrote:
}
} > if (autoload -U 2> /dev/null); then
} >
} > First zsh forks the subshell, and then the subshell forks again
}
} Bart sent me the strace output and there he also repeated the line
} above, but slightly different:
}
} if (autoload -U 2>& /dev/null); then
}
} So, Bart, if that is the form you have in .zshenv, this explains the
} processes.
The second is indeed the form I had at the time I created that strace.
Sorry about the confusion; the first time I typed it by hand and the
second I cut'n'pasted ... (and it's yet a third way in 10316, because
I cut'n'pasted _that_ while in the midst of editing it different ways
to try to get zsh to tell me why it was failing ... gaah, sorry).
} `2>& /dev/null' makes the shell look at the word after the
} redirection. This isn't a number, so the whole thing is treated like
} `&>' on file descriptor 2.
I noticed that just after I sent the strace to you and deleted the `&',
but I didn't resend the strace because I forgot about ...
} This makes it treat it as a multio and the
} funny chap with the many close()s is the zsh-tee process.
... and because removing the `&' didn't change the visible failure. Nor
does removing the entire redirection, for that matter.
} This is ugly. `&>' on file descriptor 2 makes no sense at all and if
} even Bart is confused, I think we should do something about it.
I wasn't confused ... it was an editing error. I originally tried
`(autoload -U 2>&-)' which produced an error about an invalid file
descriptor, and then I inadvertently changed only the `-'. However:
} Make `2>& <non-number>' be silently treated like `2> <non-number>'?
I'd vote for that anyway.
} > Now, the odd thing is, the subshell calls _exit(0), so you'd think that zsh
} > would take the "then" branch of the "if" -- but it doesn't, it takes the
} > "else" branch. So there must be two race conditions (?) here -- one in the
} > subshell where it loses track of its child, and another where the topmost
} > zsh mishandles the exit of that subshell.
}
} I'm not sure any more if this is really a race condition. I suspect a
} memory corruption of some kind, triggered by importing $FPATH from the
} environment (which would also explain why I can't reproduce, with
} different allocation behaviours and all that).
And the memory corruption ... steps on the exit status of the subshell as
returned to the parent, somehow? I can't see how that could be ... the
subshell is calling _exit(0) but the parent still takes the false branch.
Hrm.
} And the initial setup of fpath also depends on the site-function dirs
} that are automatically added and so on...
I do NOT compile with --enable-function-subdirs, if that matters.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~2000-04-06 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-06 8:18 Sven Wischnowsky
2000-04-06 9:51 ` Bart Schaefer [this message]
2000-04-06 15:56 ` Zefram
2000-04-06 16:42 ` Bart Schaefer
2000-04-06 17:21 ` Zefram
-- strict thread matches above, loose matches on Subject: below --
2000-04-06 10:49 Sven Wischnowsky
2000-04-05 8:03 Sven Wischnowsky
2000-04-05 5:09 Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1000406095141.ZM15654@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).