[Nut-upsdev] building NUT on Mac OS X Yosemite (website/documentation)

Charles Lepple clepple at gmail.com
Wed Dec 31 16:35:53 UTC 2014

On Dec 30, 2014, at 7:40 PM, hyouko at gmail.com wrote:

>> The only thing we need to watch out for is when the parameters to printf have '%' embedded in them. Probably not a problem for the DDL, since '%' has special meaning in URLs, but using 'printf %s' should avoid problems down the road.
> mmh.. if we want to add support for '%'s we could do something like
> this (not sure if it's worth doing):
> https://github.com/zykh/nut-website/tree/issue7
> Can you test it on OS X preferably dropping in the ddl dir also some
> '%' files and updating driver.list.in accordingly?
> Something like the following ones should be enough:
> https://drive.google.com/file/d/0BxWv_9cok7BKVDcxdWlPX2tTM00/view?usp=sharing

That works for me.

It's up to you whether the added complexity of the escaping logic is worth having - simply checking for '%' and bailing out would be sufficient. But since this works already...

> Second thought on the sort-thing: at the moment all's well and smooth,
> but in future, if we want to go 2 digits in version numbers, we'll
> need to improve it (either with more pipes and substitutions - you'd
> love it - or with a simple implementation of sort that does what we
> want it to do and nothing more).

If we have two digits in version numbers, it might make sense to move the logic into a Python script, or something similar. But we can worry about that later.

My concern is not so much with complex pipes, but with the difficulty in debugging them. As you have seen, the intermediate targets (such as some of the index.txt files) get cleaned up by make when things work, but if a step fails, the intermediate files are there for inspection. I really don't want to create more work for you now, but if we decide to extend this in the future, I would like to put some of the lists of targets into text files (rather than just keeping them in variables). For me, this would have helped pinpoint the exact origin of the "echo -e" problem.

Please don't take this as criticism, or a request to rewrite it now. I think the overall effect is excellent, and I am just pondering ways that might make it easier for others to help add new features in the future.


Charles Lepple
clepple at gmail

More information about the Nut-upsdev mailing list