[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: FAI patches and feedback
From: |
David Allouche |
Subject: |
Re: [Gnu-arch-users] Re: FAI patches and feedback |
Date: |
Tue, 07 Sep 2004 23:59:25 +0200 |
On Tue, 2004-09-07 at 14:01 -0400, Aaron Bentley wrote:
> David Allouche wrote:
> > How would you call it? There is already a "fai export" command.
>
> Well, that's the rub, isn't it? The shell behaviour is meant to be a
> fallthrough, not the main behaviour.
We can always fall back to "setenv NAME VALUE" or "setenv NAME=VALUE" or
both. The sh "export" builtin is not all that useful without an
assignment.
> > There are other annoying behaviours caused by not-quite-sh behaviour.
>
> Sure. The question is how far I should go in emulating sh. Too little,
> and it's annying to use. Too much, and I'm duplicating effort.
>
> > For example "help | grep foo" is not correctly parsed as a pipe,
>
> When I want to pipe within fai, I just prefix the command with 'fai'.
Nice trick.
> But this also suggests that we need an apropos command.
Or "fai help --apropos" since you seem to love options.
> > and you
> > cannot no longer use the kind of ugly one-liners you could use in tlash,
> > for example:
> >
> > mirrorv `upstream` ; library-add `upstream` ; missing-from
> > $(latest-revision `upstream`)
>
> Since mirrorv isn't a Fai command, I'd expect that to fall through to
> the shell.
Correct. I just got this one out of ass. I should probably have looked
in a more appropriate place.
> > where "upstream" read the contents of the `tree-root`/{arch}/+upstream
> > file used by the pqm submission script. That one line was useful to
> > monitor the application of a merge request.
>
> If it's something you do at all often, you can make it an external
> command. It looks a lot like revisions --missing-from, too.
Yes. It's basically revisions --missing-from with mirroring and working
around a bug/limitation of aba. Bad example.
> > Probably the policy is that in fai you should not have to write one-
> > liners... I'm not convinced that is a good policy. Some kind of non-
> > trivial command language is useful. And please, not something with
> > bracketitis :)
>
> I'll think about it. My main focus is on avoiding those cases in the
> first place.
No rush anyway.
--
-- ddaa