Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On 05/20/2014 07:16 PM, Brian Mathis wrote: This is a bug in validate_re(), even though there is a workaround. Arguably so. One could also argue, on the other hand, that regular expressions are matched by *strings* and nothing else. Sure, we've been spoiled by bash and perl which don't give damn and implicitly convert to string every chance they get. But that isn't a universal truth. Point in fact irb(main):001:0 puts it works! if 5 =~ /[0-9]+/ = nil I agree that it *is* inconvenient to check for two cases is numeric or contains a number when logically the former implies the latter. I also think that implicit string conversion would be a beneficial feature for validate_re. But it is not necessarily a bug. Cheers, Felix -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/537C63ED.2060109%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On Wed, May 21, 2014 at 4:29 AM, Felix Frank felix.fr...@alumni.tu-berlin.de wrote: On 05/20/2014 07:16 PM, Brian Mathis wrote: This is a bug in validate_re(), even though there is a workaround. Arguably so. One could also argue, on the other hand, that regular expressions are matched by *strings* and nothing else. Sure, we've been spoiled by bash and perl which don't give damn and implicitly convert to string every chance they get. But that isn't a universal truth. Point in fact irb(main):001:0 puts it works! if 5 =~ /[0-9]+/ = nil I agree that it *is* inconvenient to check for two cases is numeric or contains a number when logically the former implies the latter. I also think that implicit string conversion would be a beneficial feature for validate_re. But it is not necessarily a bug. Cheers, Felix If validate_re() is only effective on strings, then, in a dynamically typed language such as ruby/puppet, it better make sure it's casting to a string inside the function. Forcing the use of quotes is a workaround for something that it should be doing and creates inconsistency in the interface. Forcing the user to be aware of the internals of the function in order to use it defeats the point of using functions. One of the big problems here is that sometimes it works and sometimes it doesn't for the same data, depending on where you got it and what you did with it, which is clearly a bug. I'm not sure how else you can define a bug other than actual behavior does not match expected behavior, when the expectation is merely that the function performs in a predictable way. ❧ Brian Mathis @orev -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
I thought hiera always returns strings? ie. $myvar = hiera('testvalue')
should return a string, and validate_re( $myvar, '[0-9]+' ) should work
just fine?
Regardless, this is inconsistent:
OK:
$var = 1000
validate_re( $var, '[0-9+]' )
FAIL:
$var2 = 2000 + 1
validate_re( $var2, '[0-9+]' )
In the first case, the number is cast as a string. In the second, it is not.
The inconsistency makes this a bug, IMHO.
R.
On 21 May 2014 18:19, Brian Mathis brian.mat...@betteradmin.com wrote:
On Wed, May 21, 2014 at 4:29 AM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
On 05/20/2014 07:16 PM, Brian Mathis wrote:
This is a bug in validate_re(), even though there is a workaround.
Arguably so.
One could also argue, on the other hand, that regular expressions are
matched by *strings* and nothing else. Sure, we've been spoiled by bash
and perl which don't give damn and implicitly convert to string every
chance they get. But that isn't a universal truth. Point in fact
irb(main):001:0 puts it works! if 5 =~ /[0-9]+/
= nil
I agree that it *is* inconvenient to check for two cases is numeric or
contains a number when logically the former implies the latter. I also
think that implicit string conversion would be a beneficial feature for
validate_re. But it is not necessarily a bug.
Cheers,
Felix
If validate_re() is only effective on strings, then, in a dynamically
typed language such as ruby/puppet, it better make sure it's casting to a
string inside the function. Forcing the use of quotes is a workaround for
something that it should be doing and creates inconsistency in the
interface. Forcing the user to be aware of the internals of the function
in order to use it defeats the point of using functions.
One of the big problems here is that sometimes it works and sometimes it
doesn't for the same data, depending on where you got it and what you did
with it, which is clearly a bug. I'm not sure how else you can define a
bug other than actual behavior does not match expected behavior, when the
expectation is merely that the function performs in a predictable way.
❧ Brian Mathis
@orev
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com?utm_medium=emailutm_source=footer
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAJGKfwCBtVtBtUezvzy42vuXas%2BWFs1W9jkC_VeLXo3GSZoY1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On Monday, May 19, 2014 6:45:56 PM UTC-5, Brian Mathis wrote:
I'm seeing this issue with the current version of stdlib. When getting
numeric data from hiera, or performing math on a variable, validate_re()
fails when using the following regex:
'[0-9]+'
Fascinating.
Here are some test cases:
Getting data from hiera
# Hiera data:
# ---
# testvalue: 1234
FAIL:
$myvar = hiera('testvalue')
validate_re( $myvar, '[0-9]+' )
Performing math
OK:
$var = 1000
validate_re( $var, '[0-9+]' )
FAIL:
$var2 = 2000 + 1
validate_re( $var2, '[0-9+]' )
I've had to resort to quoting variables in validate_re, like this:
OK:
$var3 = 3000 + 1
validate_re( ${var3}, '[0-9+]' )
However puppet-lint complains about having only a variable inside
double-quotes, so I'm considering solving this with the very ugly:
validate_re( X${var3}, 'X[0-9+]' )
Yet your solution using ${var3} is perfectly good thing to do to convert
a variable of uncertain type to a string. I'd tell puppet-lint to go play
in a clothes dryer.
Alternatively, you could try this instead:
if not is_integer(${var3}) or (${var3} 0) {
validate_re( ${var3}, '[0-9]+')
}
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ff0438de-833c-4207-a605-5cc82c427efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: validate_re() does not correctly match numbers in some cases
On Tue, May 20, 2014 at 11:59 AM, jcbollinger john.bollin...@stjude.orgwrote:
On Monday, May 19, 2014 6:45:56 PM UTC-5, Brian Mathis wrote:
I'm seeing this issue with the current version of stdlib. When getting
numeric data from hiera, or performing math on a variable, validate_re()
fails when using the following regex:
'[0-9]+'
Fascinating.
Here are some test cases:
Getting data from hiera
# Hiera data:
# ---
# testvalue: 1234
FAIL:
$myvar = hiera('testvalue')
validate_re( $myvar, '[0-9]+' )
Performing math
OK:
$var = 1000
validate_re( $var, '[0-9+]' )
FAIL:
$var2 = 2000 + 1
validate_re( $var2, '[0-9+]' )
I've had to resort to quoting variables in validate_re, like this:
OK:
$var3 = 3000 + 1
validate_re( ${var3}, '[0-9+]' )
However puppet-lint complains about having only a variable inside
double-quotes, so I'm considering solving this with the very ugly:
validate_re( X${var3}, 'X[0-9+]' )
Yet your solution using ${var3} is perfectly good thing to do to convert
a variable of uncertain type to a string. I'd tell puppet-lint to go play
in a clothes dryer.
Alternatively, you could try this instead:
if not is_integer(${var3}) or (${var3} 0) {
validate_re( ${var3}, '[0-9]+')
}
John
I have decided to exclude these files from that puppet-lint test, so I can
use double-quotes only. However, if validate_re() is expecting to only
operate on a string, it should be doing this internally and not forcing it
upon the user to make an explicit cast to a string. This is a bug in
validate_re(), even though there is a workaround.
❧ Brian Mathis
@orev
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CALKwpEyxD7Y%3Deo%2BWVjghirYsqXXsHiXS1wDZooFk9t6CZc-X%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
