Excerpts from Philip Brown's message of Mon Feb 09 17:31:42 -0500 2009: > > > echo I'm the postinstall script for $(GARNAME) v$(GARVERSION). > > > > > > for i in /tmp/*; do > > > echo Found $$i in /tmp; > > > done > > > endef > > Errr... this sort of usage disturbs me.
[Assumes you're not commenting specifically on the dumb example used to show variable escaping and a general overview...] The use that brought this to my mind was the docbook and xsl stuff where (since I was templating from rhel) I used version numbers in directory names. To make the script easier to maintain, I turned paths including the version info into paths with variables in them. This leads to a case of script modification every time a version changes. > My programmers intuition suggests that the first thing to be done, would be > to have a maintainers-public review of that script. The script is 'fine.' By it's nature, it's a long stream of registration statements . It could be turned into a few loops (I didn't since I wanted it out so I could build off of it), but that wouldn't alleviate the need to twiddle it each time. It doesn't 'need' to use this functionality, but doing so will lessen (not eliminate) maintenance requirements. It's in svn (public) already if you care. If you want to say that version numbers shouldn't be in path names and make that a CSW convention (maybe it already is?) that's fine. It would (in this case) remove the need for this type of 'macro' expansion. This is common elsewhere though (see rpm). > If the script can be rewritten in a cleaner fashion, then this "other > method" of doing things, may be completely unneccessary. There are ways to avoid needing this functionality. Many scripts would never need it. That doesn't mean that it doesn't have uses though. You'll note that rpm provides a built-in macro language that is used for this type of task quite regularly. That may be, in part, due to the directory structure that rhel uses (where version numbers are frequently used in paths), but regardless, there are cases where this can be a handy thing. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting.
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/devel
