From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: ****
X-Spam-Status: No, score=4.8 required=5.0 tests=RCVD_IN_BL_SPAMCOP_NET,
	RCVD_IN_SBL_CSS autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 1859 invoked from network); 13 Nov 2022 03:39:01 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 13 Nov 2022 03:39:01 -0000
Received: from MTA-15-4.privateemail.com ([198.54.127.111]) by 9front; Sat Nov 12 22:35:11 -0500 2022
Received: from mta-15.privateemail.com (localhost [127.0.0.1])
	by mta-15.privateemail.com (Postfix) with ESMTP id 9847818000A2
	for <9front@9front.org>; Sat, 12 Nov 2022 22:35:09 -0500 (EST)
Received: from localhost (unknown [185.100.87.238])
	by mta-15.privateemail.com (Postfix) with ESMTPA id D5D4E18000A1
	for <9front@9front.org>; Sat, 12 Nov 2022 22:35:08 -0500 (EST)
Date: Sat, 12 Nov 2022 19:35:05 -0800
From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Message-ID: <Y3BlG+FFjpQOMBFk@alice>
References: <9630E999FCA18103578EE0C514F78687@wopr.sciops.net>
 <14C5796F1CAB41005D892E08A68F9EAC@eigenstate.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14C5796F1CAB41005D892E08A68F9EAC@eigenstate.org>
X-Virus-Scanned: ClamAV using ClamSMTP
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: secure virtualized firewall XML over ORM pipelining STM interface 
Subject: Re: [9front] this history(1) is scratched
Reply-To: 9front@9front.org
Precedence: bulk

ori@eigenstate.org once said:
> Quoth qwx@sciops.net:
> > The thing is, this change is already a few months old, and I cannot
> > imagine that the script has not worked for anyone in all of this time,
> > including when it was first pushed, or that absolutely everyone has
> > been using the old C version without noticing it.  This behavior in
> > awk is surprising to me, but is not 9front-specific.  What the hell is
> > going on?  Can anyone else reproduce this?  Any idea what I could be
> > doing wrong?
>
> ...I'm slightly embarrassed to admit that I've got the old history
> in my binds before the new one, so I didn't notice I was using the
> old one.

I think we all are. The default namespace set up by init(8) binds
/rc/bin after /$cputype/bin. A sysupdate(1) followed by a clean
build wouldn't blow away the old binary. Maybe we should detect
duplicate files in /bin and warn about them when updating.

% cat /bin/bindups
#!/bin/rc

rfork e
fs = `{cd /bin; ls | sort | uniq -d}
ds = `{ns | awk '$NF == "/bin" { print $(NF-1) }'}
>[2]/dev/null for(f in $fs) ls -ld $ds^/$f

Cheers,
  Anthony