[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

> > 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]