directory-handling with nALFS
bookreader at gmx.com
Sun Apr 4 09:37:02 PDT 2004
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.
> Think of this way: Vassili's YAALFS is a fully conformant ALFS
> implementation (that creates bash scripts), so if you fed it one of
> these profiles how would you expect it handle a pre-existing directory,
> without additional information in the profile to tell it do that?
I only can tell, how I would do that:
cd whatever && additional command[s|chains]
This way I don't get struck with an existing directory and with the cd I could
asure, that the directory is there and accessible.
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.
> Also, <mkdir> accepts a "permissions" parameter, to specify what the
> desired permissions on the directory should be. What should happen if
> the directory already exists but the permissions are different? (This
> would happen if the profile has already been run, but then changed to
> specify different permissions).
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
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.
So I think of command usage.
'mkdir' is intended to create a directory. To change the permissions, you
could use 'chmod'. And if you compile commands, you could do that as well.
> I would disagree that there is "no benefit using it", as any Makefile
> system is not going have to a user interface, provide logging into
> usable XML log files, be executable on a remote system (in a future
> release of nALFS), etc.
For me it looks like this:
- The userinterface is nice for testing, but nothing I really need (even more
as it is stil very unstable).
- 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
- 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
I like to go out and enjoy the sun, riding the bike, ...
So if I have an idea, on how to increase my sparetime with a little different/
extra work - I will do that job - and I supposed, this could be true for all
Enjoy what you do, where you do and when you do!
More information about the alfs-discuss