> That's good to hear--there's at least one other crazy person here! :-)
That's me, crazy...
> >As long as you're at it, you probably want a tolower() and toupper() functio
> n.
>
> And, left(), right(), substr(), length(), sprintf(), s///, and others.
No. left/right/substr are from before regexp's, and should be shot. Length,
probably not. Sprintf, maybe. Only maybe. s/// no, because that breaks the
whole convergence thing.
Cfengine is not a programming language - it may have some language-like
features, but it is not a programming language.
> >You can get "ignore case" on regular expression matching with PCRE '(?i)',
> >but converting to lower or to upper on output is harder (and if you want
> >convergence, you DON'T want what Perl does... :-)
>
> There are lots of things where I don't want what Perl does. :) But
> along the lines of convergence, I don't see that a regreplace type of
> function is any more or less convergent than splitstring() or join().
> Both of those existing functions take existing variables and create a
> new variable while leaving the original(s) untouched.
I agree (which is why I disagreed with s///).
> >Also, in your model, regreplace needs a 4th argument - "first" or "all", to
> >give you the equivalent of /g substitution. While "first" can be a bad
> >thing, there is already precendent for that in Cfengine in the replacement o
> f
> >lines in files...
>
> Agreed, a first/all argument is needed.
>
>
> >
> >-Dan
> >
> >> On Tue, Mar 02, 2010 at 08:33:15AM -0500, nwat...@symcor.com wrote:
> >> >I don't think there is a function at present for string search a replace
> >> >actions out side of file editing. Perhaps look at it from a higher level
> .
> >> > Why is string manipulation needed?
> >>
> >> There are two reasons, one specific, and one general.
> >>
> >> The specific reason is that I am trying to build a somewhat more robust
> >> template library (which if I ever get to work, I will post to the list).
> >>
> >> To do this, I am trying to convert a file from the form of
> >> "/some/path/to/file" into something like
> >> "/path/to/repo/_some_path_to_file".
> >>
> >> This is trivial with two regexes. Using quasi-cfengine notation, and
> >> a hypothetical regreplace(string,find,replace) function, something like
> >> this would work:
> >>
> >> vars:
> >> "orig" = "/some/path/to/file";
> >> "new" = regreplace(
> >> regreplace("${orig}", "/", "_" ),
> >> "^",
> >> "/path/to/repo"
> >> );
> >>
> >>
> >>
> >> The general reason is that string search and replace is a very useful
> >> tool. It doesn't really matter the what the specific problem actually
> >> is, since this is a more general issue. A good tool is useful in lots
> >> of different situations, including those in which it was not originally
> >> intended.
> >>
> >> There have been several occasions where a simple string replacement would
> >> make certain promises simpler, but I have attempted to work around them.
> >> But having to shell out and make two calls to outside binaries--one
> >> of them being echo!--just to do a simple string manipulation seems
> >> counter-productive, inefficient, and much more error prone (especially
> >> due to the hazards of shell quoting).
> >>
> >> Here's another example, albeit slightly contrived. You have a system
> >> where you want to start hashing user home directories in the form of
> >> "jbecker -> /home/j/jbecker" (for example). Based on some
> >> list of users, there is a set of promises to ensure that the accounts
> >> exist, including calling 'useradd'. Having a short set of promises to
> >> convert the string "jbecker" into "/home/j/jbecker" is fairly easy using
> >> a search and replace function. I can envision a situation where
> >> cfengine could actually handle the migration of existing "unhashed" user
> >> home directories to "hashed" ones, but only if it supports better string
> >> handling routines.
> >>
> >> Of course, one can always just hand off a username to a Perl script as
> >> well.
> >>
> >> I really want is a general solution (which is why I did not simply ask
> >> how to munge a path). Once I--and everyone else--has that, the
> >> specifics should be simple. :)
> >>
> >>
> >>
> >> --
> >> Jesse Becker
> >> NHGRI Linux support (Digicon Contractor)
> >> _______________________________________________
> >> Help-cfengine mailing list
> >> Help-cfengine@cfengine.org
> >> https://cfengine.org/mailman/listinfo/help-cfengine
>
> --
> Jesse Becker
> NHGRI Linux support (Digicon Contractor)
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
