Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Vlad Glagolev (e541968349f5b85e4be5bfc9ba8e65bf4534d827)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Vlad Glagolev (e541968349f5b85e4be5bfc9ba8e65bf4534d827)
  • Date: Mon, 10 Nov 2008 01:05:07 -0800

On Sun, 9 Nov 2008 23:11:53 -0500
flux <flux AT sourcemage.org> wrote:

> Eric Sandall (eric AT sandall.us) wrote [08.11.09 22:48]:
> > On Sun, 9 Nov 2008 15:21:31 +0100
> > Thomas Orgis <thomas-forum AT orgis.org> wrote:
> >
> > > Am Fri, 7 Nov 2008 23:53:39 -0500
> > > schrieb flux <flux AT sourcemage.org>:
> > >
> > > > Does this matter for our own spells? We aren't BSD, and *we*
> > > > have the GNU extensions. If this is a patch to be submitted
> > > > upstream I understand the logic of your argument, but otherwise
> > > > I don't see the need for a separate "portable" sedit.
> >
> > I believe sedit is from before GNU sed had '-i', but we've
> > continued to use it afterwards. It's nice to have if you're trying
> > to do a cross-compile into a different directory to bootstrap an
> > SMGL system from another (e.g. install Debian on SPARC and then use
> > INSTALL_ROOT to build SMGL somewhere).
>
> 1) Debian *doesn't* have GNU sed? I'm pretty sure such a Debian
> install would make sed -i available, so that sounds like a bad
> example. However, I understand the force of your argument, and that
> still holds. That problem could be mediated by having more diverse
> SMGL basesystem chroots available. Any volunteers to automate builds
> for more architectures?

Debian wasn't for the example of not having GNU sed, but rather that
we'd use a non-SMGL system to bootstrap. ;)

> 2) sedit on SMGL is provided via part of sorcery itself, and isn't
> available as a binary. According to [1], it currently just runs sed -i
> anyway, so calling the sorcery sedit on a system lacking GNU sed will
> still fail.
>
> Alternatively, a roundabout (and slower) means of editing a file "in
> place" can be done by piping output to sed, having sed act on the
> stream, and then storing the output back to the same file via pipe or
> similar.
>
> Example: cat FILE | sed -e 's/something/ELSE/' > FILE
>
> That example should always work as long as both sed and cat are
> available, regardless of the version of sed. It should also, in
> theory, work regardless of the shell being used (inputting the file
> via (<FILE) is a bash-ism). Perhaps having a "backup" sedit in
> sorcery would be a good idea? Though, in my opinion, only if we have
> a smart way of detecting if GNU sed is installed and using sed -i by
> default since that would be much faster. This is tough to do, since
> checking on each run of sorcery would slow it down, but having it set
> in a config file, while faster, wouldn't make much since, because at
> that point you might as well manually call sed/sedit/whatever anyway.
>
> [1]: http://www.sourcemage.org/HOWTO-Sed

I seem to recall it used to check if `sed -i` was usuable and if not,
do the pipe or a temp file. If it's just `sed -i`, we should deprecate
it and switch all our spells to directly call `sed -i` OR modify sedit
to work on systems that don't have GNU sed (and a recent enough one)
and work around that, if we care. ;)

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285

Attachment: signature.asc
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page