[26376] in Source-Commits
Re: /svn/athena r25538 - trunk/debathena/config/reactivate/debian
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu May 31 18:14:47 2012
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <alpine.GSO.1.10.1205311805360.18441@multics.mit.edu>
Date: Thu, 31 May 2012 18:14:44 -0400
Cc: source-commits@MIT.EDU
Message-Id: <71A5FCC9-11E2-4CE9-A0B2-91F466AD372D@MIT.EDU>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Content-Transfer-Encoding: 8bit
> Doing the edits as a separate commit from the copy would probably make the history easier to follow N years from now, but nor is this particularly complicated.
Yeah, I can never remember whether "svn mv" is actually useful in a commit log or not.
>> +sed -i -e "s|_VARRUN_|$(readlink -f /var/run)|g" \
>> + -e "s|_VARLOCK_|$(readlink -f /var/lock)|g" \
>> + -e "s|_DEVSHM_|$(readlink -f /dev/shm)|g" ${FSTAB}
>
> This should work, but I would think that
> sed -e foo -e bar -e baz < ${FSTAB}.in > ${FSTAB}
> would be more ... portable, or something.
> I guess maybe it would be a bit more efficient on the read/write syscalls.
>
> But ... if you don't want to change it, I'll ack it anyway.
I'm not opposed to changing it, but it's not like we're going to use this on anything but GNU/Linux, and I'll weep for humanity if we ever upstream this. If using I/O redirection is better performance-wise, I'm happy to change it. Otherwise, inertia is powerful.
-Jon
