in reply to why dosn't my code work?

Btw this i'm just coding for fun.

Maybe then you don't need our help? and we should spend our time on people who are coding because they are trying to learn, or trying to earn a living, or trying to help someone else earn a living? Or even trying to fulfill a life-long dream as software inventor?

I would hope that you are trying to learn something from this "fun". What output are you getting? What do you mean "doesn't work"? We can't read your mind.

If I were to make a vague guess here, you are trying to read three things (name, age, gender) from STDIN. You then print out three new lines to STDOUT. You think that printing those new lines should send stuff to STDIN. And that the stuff will be automatically read and printed out in the final three lines, just as if you hit the return key 3x on the keyboard.

If so, some points to note:

Best, beth

Replies are listed 'Best First'.
Re^2: why dosn't my code work?
by almut (Canon) on Apr 21, 2009 at 11:24 UTC
    chomp($name... female;} is not some sort of form definition that only gets activated when you issue the print "\n\n\n" or the <> at the bottom of your sample code. I can see how someone used to working with HTML might think that way, but this is procedural code.

    That speculation about the OP's thinking seems a little far-fetched to me. I'd say the structure of the code looks like a rather straightforward attempt at something that's supposed to sequentially ask the user a couple of questions, and print out a summary at the end. Just like those typical exercises you find in many introductory textbooks on programming. Or like a simple interactive install script querying some parameters.  I presume the OP is well aware of the procedural characteristic, and that <return> needs to be hit after every answer. And the print "\n\n\n"; was presumably just intended to create three lines of vertical space between the input and output section. (Only the OP can tell, though...)

    The reasons the script 'doesn't work' is just a couple of newbie glitches like using == in place of eq, an \n-outside-of-string typo, or suboptimal things like using barewords instead of properly quoted strings. With those fixed, the script works fine as is.

    A corrected version could look like this (which would also run under use strict):

    use strict; print "What is your name?\n"; chomp(my $name = <>); print "Thank you $name. What is your age?\n"; chomp(my $age = <>); if ($age <= 18) { print "Are you a boy or girl?\n";} elsif ($age > 18) { print "Are you a man or woman?\n";} print "Type M or F.\n"; chomp(my $char = <>); my $gender = 'unknown'; if ($char eq 'm' || $char eq 'M'){ $gender = 'male';} elsif ($char eq 'f' || $char eq 'F'){ $gender = 'female';} print "\n\n\n"; print "Name: $name\n"; print "Age: $age\n"; print "Gender: $gender\n\n"; <>; __END__ What is your name? Almut Thank you Almut. What is your age? 17 :) Are you a boy or girl? Type M or F. f Name: Almut Age: 17 :) Gender: female

    Due to Perl's convenient string-number conversions, it even accepts age input which is not strictly numeric (with use warnings, you'd get a warning, though).

    Just two more remarks:

    As the two inequality tests if ($age <= 18) and elsif ($age > 18) are complementary, the latter condition seems superfluous1. You might argue that it's ok for documentary purposes, but from a maintainability point of view, it's preferable to just use a plain if (...) { } else { }, because then you wouldn't need to worry about keeping the two conditions in sync, should the critical age ever need to be changed.

    On the other hand, the code handling the gender answer might additionally want to provide some defined outcome (e.g. "unknown") in case the user enters something unexpected like 'h'.

    ___

    1  this kinda reminds me of the following snippet of C++ code once posted on The Daily WTF  ;)

    bool is_true(bool val) { if (val == true) return true; else if (val == false) return false; else return !true && !false; }

    (from memory)

      I think your and moritz's read (the bit about eq) is most likely what the OP meant by "not working". moritz and I were writing our posts about the same time. I missed the eq/== problem when I read the OP's code and didn't see moritz's post until after I posted mine.

      I rather suspect I got distracted by the "just for fun" comment coupled with the lack of explanation of what didn't work. For a few seconds I actually thought the post was maybe even a well-meant spoof of some of our less articulate questions.

      But then on second thought it felt trivializing, though I honestly wasn't sure who or what was being trivialized: the OP's own curiosity in learning Perl or our efforts at answers. One should never trivialize efforts at learning - even if that learning is only for pleasure. Some would argue that learning (and coding) for pleasure is in fact the purest form of learning and the *least* deserving of trivialization.

      Best, beth

        The question isn't posed properly, and I would suspect that is the OP's issue in learning perl. The scientific method and critical thinking are both absolutely necessary; if you are merely a pinball bouncing about a field with no control, programming will be miserable.

        That being said, I don't think it's in the rules you can't post here if you're coding for fun. My first project before becoming employed in the field was when I was young- and you can guess, it was just for fun.
        thanks, when i said fun i meant that's it's fun for now, but when i grow up i would like to get a job in computer porgramming or something simmilar.