Extract variable length numbers (tab delimitered) from a string?
in [Perl]
|
Prev: FAQ 9.11 How do I redirect to another page?
Next: FAQ 7.18 How can I access a dynamic variable while a similarly named lexical is in scope?
From: Marc Girod on 6 Aug 2010 09:32 On Aug 6, 10:25 am, Marc Girod <marc.gi...(a)gmail.com> wrote: > With all respect due, my own hubris would play Hall against Kernighan. My name is Wall, Larry Wall... Marc
From: Uri Guttman on 6 Aug 2010 09:58 >>>>> "w" == wolf <wolf(a)gsheep.com> writes: w> Ted Zlatanov schrieb: >> On Wed, 04 Aug 2010 16:13:38 -0400 Sherm Pendley >> <sherm.pendley(a)gmail.com> wrote: >> SP> Ted Zlatanov <tzz(a)lifelogs.com> writes: >>>> So there's value in exploration and cleverness. >> SP> Certainly, exploring edge cases is part of the learning process. When SP> it comes to production code, though, I find more value in simplicity. >> >> I mean in production too. Today's clever code is tomorrow's standard. >> For example the Guttman Rossler transform at first was clever and >> confusing (I've had to explain it to beginners more than once); >> gradually it became established and today Perl 6 does it internally by >> default. w> ... and now I find myself learning about sorting algorythms to w> understand the answer <G>. it is well documented in Sort::Maker. in fact that module can generate sorts in four (count'em four!) different styles so you can learn them all. uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: ccc31807 on 6 Aug 2010 12:18 On Aug 4, 3:21 pm, "Uri Guttman" <u...(a)StemSystems.com> wrote: > my head), 40% coding and 20% debugging. and much of the debugging is > very easy stuff (at least to me). my take on the general coder > population is like 10% design (if that much), 40% coding and 50% > debugging. well it seems like that from what i see and hear. debugging > should be easy IMO if you design the code right. a given bug should be > quickly isolated to the area that handles that part of data. this brings > up the design philosophy of high isolation of modules. again, few adhere > to that idea so they have many places which could cause a given bug > thereby making debugging harder. i don't use a debugger, IDE or anything > but print and i get working code without pain. brains over typing! :) At least part of this depends on the problem domain. The vast majority of my work depends on user input, and almost all the 'bugs' that make it past release occur with bad input. For example, an automated process stopped working one day, and after quite a while debugging, I took a look at the input data and discovered that a user had set a password beginning with '#' -- the code skipped all lines as comments beginning with # so it treated the password as a comment and couldn't continue because the password field was blank. It's very difficult to foresee all the ways that users can enter data. Even if the user is a program you can't necessarily depend on it. I sometimes get data generated by a database that consolidates blank fields, which is a problem if you are using split() or a RE to destructure input data. Then again, some people don't classify user errors as bugs, but user errors act just like bugs. CC.
From: Sherm Pendley on 6 Aug 2010 23:24 ccc31807 <cartercc(a)gmail.com> writes: > password beginning with '#' -- the code skipped all lines as comments > beginning with # so it treated the password as a comment *Please* dont tell me you're doing eval($password)...?!?!? sherm-- -- Sherm Pendley <www.shermpendley.com> <www.camelbones.org> Cocoa Developer
From: Peter J. Holzer on 7 Aug 2010 07:35
On 2010-08-07 03:24, Sherm Pendley <sherm.pendley(a)gmail.com> wrote: > ccc31807 <cartercc(a)gmail.com> writes: >> password beginning with '#' -- the code skipped all lines as comments >> beginning with # so it treated the password as a comment > > *Please* dont tell me you're doing eval($password)...?!?!? How did you get that idea? "#" is a very common comment character in config files and code like while (<$config_h>) { chomp; s/#.*//; my ($key, $value) = split(/\s*=\s*/, $_, 2); next unless $key; ... } is a common way to ignore the comments. And now you have a config file like this: # this is a config file for the foo application # # first define the database connection: dsn = dbi:Oracle:ORCL user = scott password = tiger#4 # then some ui preferences background = green ... the password will be truncated from "tiger#4" to "tiger". Oops. Obviously that's not exactly what happened in Carter's case, because he mentioned only "lines beginning with #", so he probably has an even simpler file format where the password stands alone in a line. Maybe something like "first line is the user name, second line is the password". hp |