Wednesday, May 20, 2009

Was Nadav, or Aharon, the firstborn?

In parshat Bemidbar Sinai, there is some interesting trup on a pasuk, which Baal HaTurim comments on. In Bemidbar 3:2, we have the pasuk, and trup, pictured to the right. Note the vertical line right after the word habbechor. What is the meaning of this line? Why not just say that the bechor was Nadav??

The Baal Haturim picks up on this, and he writes what is pictured to the right. Namely, that there is a pasek between habechor and Nadav, to say that it does not refer to Nadav. For Nadav died without children, and there was no purpose to his bechora. Rather, it refers to Aharon, who was the bechor compared to Moshe. (This despite Miriam presumably being older than either.)

Meshech Chochmah cites this Baal HaTurim approvingly, and extends it.

I am not certain how to take this Baal HaTurim. Does he mean this on the level of peshat or derash? Is he claiming that this is the intent of the author of the trup (whether that author is Hashem, or some parshan)? Is he saying this to the exclusion of any other explanation the Baal HaTeamim puts forth? Depending on the answer, I either would view it as a nice and cute derasha or an incorrect peshat.

I can confirm that it is actually a pasek. Even though the trup on the word preceding is a munach, this is not an instance of munach legarmeh (which is orthographically identical). For a munach legarmeih occurs in the clause of a revii, while this is in a clause of an etnachta.

If the Baal HaTurim is saying that this is the only position of the Baal HaTeamim, that he is trying to bind habechor to Aharon rather than Nadav, then I would certainly disagree. Note that there is a tipcha on the word Aharon. If the author of trup really meant what Baal HaTurim claims he did, he would simply have placed the tipcha on the word bechor. Rather, as it stands, tipcha subdivides a clause ending in etnachta, and so the division is into:

"And these are the names of the children of Aharon || the firstborn Nadav"

Any subsequent pasek does not have enough force to redraw these lines, and why draw the lines incorrectly in the first place?

Furthermore, we encounter the same pasek in other places, where it is clear that it does not refer to the preceding person -- once, even with identical trup. Thus, in Divrei Hayamim Aleph we encounter the following three. The first is from perek 2, and is the closest match. One could kvetch some sort of peshat in which the word habechor latches on the Chezron, but there is no need to do this. And this is identical trup to what we have locally in parshat Bemidbar. Rather, it seems that this is the patters.

The next example is from perek 3. The vertical bar after habechor is not a pasek here; rather, it designates the munach as a munach legarmeh. Regardless, there is a division here, perhaps justified by the length of words in the subclause. But habechor is separated a bit from Amnon, and we do not claim that it is supposed to go on Chevron.

The third example is also from perek 3. There is no pasek, but the pashta, rather than munach, on habechor means that it is a dividing trup. And so habechor is separated from Yochanan. There are actually irregularities on this pasuk, because of other pesukim in Yirmeyahu and elsewhere, such that bechor might mean first to kingship rather than age. See the midrashim on this. But still, I don't think that these midrashic explanations are influencing the trup.

Rather, in each instance, if we had a conjunctive, non-dividing trup mark on habechor, one might think for just-an-instance to treat it as the construct form: the firstborn of Nadav. Since it is the bechor, namely Nadav, the dividing accent is appropriate.

William Wickes gives several reasons one would have a pasek. One is the pasek distinctivum, used to make a slight distinction between words. This case would seem to meet the criteria. He also gives paseq emphaticum. Perhaps there might be some reason to highlight the bechor and give extra emphasis. But I would lean towards the first explanation. And Baal Haturim's explanation simply does not work out.

No comments:

LinkWithin

Blog Widget by LinkWithin