Regular Expression to Replace UPPER Case Text with lower case text

[Charlton Wilbur]

cc> You have completely misunderstood what I said. The people I
cc> mentioned are not idiots, they're simply ignorant. These
cc> people have well paying, responsible jobs, but the jobs are
cc> MANAGEMENT jobs, not technical or engineering jobs. Typically
cc> they have a business degree with one course in VB and one
cc> course in SQL, and they are convinced that they know
cc> everything there is to know about technology. Why? Because
cc> their opinions have been validated again and again by real
cc> world experience. Again, this is managerial and business
cc> experience, not engineering or technical experience. These are
cc> bankers and marketers and insurance executives, not
cc> programmers or software engineers.

You seem to think that "he's an idiot" can be countered by "but he's
not a programmer or a software engineer." Technical management is
equal parts technical knowledge and management knowledge, which is why
it's so often done poorly.

cc> In the first place, they aren't idiots but middle and uppermid
cc> level managers who have done well in their careers.

You also seem to think that "he's an idiot" can be countered by "he's
done well in his career." Examples of successful idiots abound;
you've even offered a number of anecdotes yourself.

cc> In the second place, I evangelize my beliefs, which basically
cc> are Perl and Python in a BSD or Linux server connected to a
cc> Postgres or MySQL DB served up by Apache.

You do a very poor job of evangelizing for Perl if you're advising
people that (a) they'll be laughed at for using it and (b) it's best
avoided, as it's 1980s technology.

Charlton

 

[ccc31807]

You seem to think that "he's an idiot" can be countered by "but he's
not a programmer or a software engineer." Technical management is
equal parts technical knowledge and management knowledge, which is why
it's so often done poorly.

Not at all. 'Idiot' means someone with a very, very low IQ, a retarded
person. 'Ignorant' simply means lacking information. It shouldn't
surprise you that someone who spent all his career on the business
side lacks knowledge and experience on the technical side.

You also seem to think that "he's an idiot" can be countered by "he's
done well in his career." Examples of successful idiots abound;
you've even offered a number of anecdotes yourself.

Again, no. A successful person isn't an idiot. He may do idiotic
things, he may be ignorant in certain knowledge domains, but he isn't
an idiot.

You do a very poor job of evangelizing for Perl if you're advising
people that (a) they'll be laughed at for using it and (b) it's best
avoided, as it's 1980s technology.

(a) In some circumstances, you ~will~ be laughed at for using
particular technologies, including Perl. This is simply a statement of
fact. (b) Do you not recognize sarcasm? At least Tad recognized this
as an attempt at humor.

Part of this relates to some very recent personal experience. Since
January 1, I have been told the following:
(a) The place to set the budget and the schedule is in the scoping
phase of the project. ('Scoping' is where you determine whether you
have a problem that can be addressed by technology.)
(b) You don't involve technical people in the analysis and design
phases of a project because they will get you bogged down with
discussions involving technical solutions, and analysis and design
does not consider technologies.
(c) You set the requirements, design the project, implement the code,
and deliver it. If you have to backtrack, i.e., iterate, it means you
failed to successfully complete a prior stage.
(d) You debug and correct an application just before delivery. That
way you can catch all the errors at one time and you don't need to
waste any time in previous stages testing for and correcting errors.

Yeah, I know. But you really can't call people four or five levels
above you, and who control the finances and can kill your project,
idiots. Even if they have idiotic ideas. As far as I can ten, our
schools are churning out MBAs with their heads filled with nonsense
like the above. And to be totally candid, it appears that some portion
of their (bad) attitude toward technology is earned, at least to the
extent that engineers and developers ignore the business side.
Like ... how do we turn this into money?

This has gotten way off thread. I won't be replying. You can have the
last word on this topic.

CC

 

[Peter J. Holzer]

[Solution: Use \L]

p> The reason I didn't go the CFusion newsgroup first is that CF
p> runs with a limited perl engine and I figured you guys would
p> know more about regex than the cf group (eek)

Er, no, while CF may have a PCRE library glommed into it somewhere, it
has no Perl content at all; and "Perl compatible" regular expressions
aren't.

Maybe not, but \L works in perl also (reading this thread (yes, I'm a
bit behind ...) I was astounded that nobody came up with this).

hp

 

[Joost Diepenmaat]

[Solution: Use \L]

p> The reason I didn't go the CFusion newsgroup first is that CF
p> runs with a limited perl engine and I figured you guys would
p> know more about regex than the cf group (eek)

Er, no, while CF may have a PCRE library glommed into it somewhere, it
has no Perl content at all; and "Perl compatible" regular expressions
aren't.

Maybe not, but \L works in perl also (reading this thread (yes, I'm a
bit behind ...) I was astounded that nobody came up with this).

That's because you don't need to use a regex if you're going to use \L.
In fact \L isn't valid in a regex (only in the replacement string of a
regex replace operator) so the "regex" would be

$var =~ s/.*/\L$1/g;

while you could more easily use $var = "\L$var" or even better: $var =
lc($var);

 

[Joost Diepenmaat]

$var =~ s/.*/\L$1/g;

I meant:

$var =~ s/(.*)/\L$1/g;

Which is even more ugly.

 

[John W. Krahn]

That's because you don't need to use a regex if you're going to use \L.
In fact \L isn't valid in a regex (only in the replacement string of a
regex replace operator)

While technically true, \L is not a valid regular expression escape
sequence, it is valid in that the m// and s/// operators which use
regular expressions are evaluated as double quoted strings so \L is
valid in that context.

so the "regex" would be

$var =~ s/.*/\L$1/g;

$ perl -le'print $& if " q " =~ /\LQ/'
q
$ perl -le'print $& if " Q " =~ /\Uq/'
Q

$ perl -le'my $x = "Q"; print $& if " q " =~ /\L$x/'
q
$ perl -le'my $x = "q"; print $& if " Q " =~ /\U$x/'
Q



John

 

[Peter J. Holzer]

While technically true, \L is not a valid regular expression escape
sequence, it is valid in that the m// and s/// operators which use
regular expressions are evaluated as double quoted strings so \L is
valid in that context.

More importantly, the OP only asked about a "Regular Expression" because
he didn't understand the concept. A regular expression can never replace
anything, it can only match something. What he wanted was a
substitution. So

s/.*/\L$&/s;

or

s/(.*)/\L$1/s;

fit the question (that misconception is frequent enough that I think
everybody in this newsgroup is familiar with it). The OP also wrote that
he wasn't actually using perl but some software which uses PCRE. Of
course he might have said that only after most of the answers and even
if he had said it in his very first posting, by asking in a perl group
he must be prepared to get perl answers, not PCRE answers.

hp

 

[David Combs]

I have a whole series of anecdotes to illustrate this, but I'll leave
you with punch lines.

Yep, those are good'uns. You say you have more?

Maybe post them here for us all to see?

Thanks,

David

 

[Charlton Wilbur]

DC> Maybe post them here for us all to see?

Anecdotes don't get you anywhere; the people who are capable of
learning from them don't generally need them, and they're inadequate
to convince people who want glossy magazines and highly-funded case
studies.

Charlton