directory-handling with nALFS

Kevin P. Fleming kpfleming at
Sun Apr 4 10:39:52 PDT 2004

Reinhard wrote:

> On Saturday 03 April 2004 16:23, Kevin P. Fleming wrote:
>>There are not currently any nALFS options (specified in nALFSrc) that change 
>>the execution behavior of the handlers, and I want it to stay that way.
> Well, this tenor does not enable evolution, but OK, I bow to your decision.

It's not about evolution, it's about separation of responsibility. I 
have thought about offering a way for handlers to provide their own 
options, and will probably move in that direction, but not until after 
some more thought and discussion about how best to incorporate that into 
the configuration file.

> By the way - I get the shellscripts and Makefile right from the book - I don't 
> know what's the benefit on using profiles to get shellscripts.

People make ALFS profiles for things other than the book; many people 
have heavily customized profiles for their system builds, and they may 
want to export the relevant commands into a shellscript for some reason. 
I don't ask why, if they want to do it more power to them!

> If you look at the provided patch, I didn't touch the permission code, so if 
> the directory exists, but with different permissions, the handler will fix 
> that.

OK, I had not looked closely at your patch; sorry for that.

> If you did not want to point out the handler-code, but the 
> shell-script-handling, I only can reply the same, like you wrote in the 
> hackers-guide to alfs:
> 	a function should do one thing and do it well.

Actually that came from the Linux kernel coding standards, but I still 
agree. However, in this case "function" is referring a well-defined 
section of the source code, not an entire nALFS handler. If we applied 
it to handlers, the stage and package handlers would need to be broken 
up into many smaller pieces :-(

> - The userinterface is nice for testing, but nothing I really need (even more 
> as it is stil very unstable).

Then don't run in interactive mode :-) If you don't need the nALFS user 
interface, is there any particular reason you are creating ALFS profiles 
instead of just going directly to shell scripts?

> - logfiles should be clear and expressive. For me, using XML in logfiles is an 
> big overkill, which blow up the files unneccessary. Logfiles are known to be 
> big, so you have to deal with wrapping, versionizing and lot of other things.
> If the entries are expressive, you could easy get the information out using 
> grep. If you have to deal with lots of logfiles, one day you reach the point, 
> where you like to learn perl and regex - and then you get everything out of 
> the logfile without having xml inside.
> XML without any doubt has its benefit, but I don't need it anywhere and 
> everywhere.

When the logfiles are converted to more fully utilize XML, they will be 
much more powerful than they are today, and much more powerful than any 
combination of grep/perl would be without a ton of work. To make the log 
files more "expressive", we would have to add lines to the log for entry 
and exit of every handler, with time stamps, and some way to mark the 
system output from that handler. Once that is done, it might as well be 
an easily parseable XML file instead of just plain text, there would not 
be any particular advantage in sticking with plain text.

> - remote execution is already possible. Today. Just using ssh for example.
> I use it that way and it's ok for me. Why spending your valuable time on such 
> an item?

I want to be able to support other frontends than just an ncurses-based 
textual one. Jamie Bennett has already talked about working on a 
gtk-based front end, and I can envision other ones as well. Remote 
execution will also support being able to "disconnect" from a running 
session and reconnect later to check on progress, which ssh can't easily do.

> I like to go out and enjoy the sun, riding the bike, ...

Me too, but I also get a lot of enjoyment from software development as 
well :-)

More information about the alfs-discuss mailing list