Please ask me if you want more information , I am ready to give

Really? You mean it? Rather than you providing a cogent question with meaningful details we instead get to slowly drag them out of you based on wild guesses from the pittance you've already provided? Joy!

(See How (Not) To Ask A Question.)

Update: And it's also bad form to pretty much completely change the contents of a node without any indication it's been done.

abubacker - As you will have seen by the responses to your many question over the last day or so :

Many people have pointed you towards How (Not) To Ask A Question - this is because people here don't really appreciate having an answer demanded of them. Especially when something as simple as googling | super searching 'perl file locking' will give you a very comprehensible answer.

You will get a lot better responses if you show what you have tried, looked at or searched for so far, explaining why you are still having a problem understanding something or getting a script to work.

Monks will always help those who help themselves, but get irritated easily when they are treated like a walking encyclopedia. Finding out how to find things out is half the battle, and you really have to teach yourself that! (Although doing a Super Search at PerlMonks is probably one of the better starting places!)

You need to post examples with your questions. You gotta actually read what Fletch posted, and actually follow up on it- really read the stuff. Really really.

We also want the quickest way to get things done possible- to learn and solve problems as fast as possible. It turns out, simply asking as if people could read our minds, is *not* the quickest way, actually- it fails misserably.

The quickest way for you to get your answers now and in the future is to do as was suggested.

Invest a little time into it. A morning, perhaps. It will work like magic in the days to come.

Can you? yes. How should you? Or even, should you? Impossible to tell if we don't know more about the problem you are trying to solve.

Unless you tell us what you've tried, we're shooting in the dark about what confuses you or how to help you. We can give you advice but you may not know how to use it. Or you may just plop it in your code, but you may not know how to debug it. Or we could point you to documentation, but you may not know how to read it.

There are a zillion different ways a new Perl programmer can get confused. These may not apply to you but here are some:

• you read the documentation but it contained too much jargon and you couldn't make sense of it. If so, we need to explain the jargon.
• you tried solution X but got error messages or warnings (which ones?) - what did you try? is it a syntax error? difficulty in understanding the documentation? a typo? something further up in your code, like an undefined variable?
• you know you are supposed to use locking but you don't really understand what that means. Sometimes a new programmer will be told by a boss, teacher, or collegue "Use file locking!" without anybody explaining what that means or why it is a good solution to the problem. If so, pointing you to a solution is not enough. We also need to point you to tutorials that explain what locking is and how it works and why it solves your problem.
• you think locking is your solution, but in fact there is really a much better way to solve your problem. Sometimes people show up thinking X is the solution when Y is the problem and it can't even be solved by X (see XY Problem). That is why it is so important to explain what you expect locking to do for you and not just ask "can I lock".
• or maybe you actually mean your question literally. "can I?". Perl is a lot more powerful than certain other to-remain-nameless scripting languages. Newcomers often are concerned they won't be able to do things that every experienced Perl programmer knows is built right into the language or just a CPAN library away. In that case, why make us write an essay when a simple yes/no answer will do? :-)

For an even longer list see, I know what I mean. Why don't you?.

I hope you can see why people who really, really want to help you get just a little bit frustrated when you ask a question with no explanation of (a) why you want to do X (b) what problem you hope it will solve (c) what you have already tried to solve that problem.

Secondly, we like to see people who have put some effort in because it shows they have the temperament to really benefit from our help. It means they are willing to work to learn. Even with our help, a learner still has to work. We can't make those brain cog wheels turn for you. Only you can do that. If you aren't sure how to search for answer on your own, then make that your question. Instead of "can I lock a file", ask "how do I go about looking up information about locking files in Perl?"

Here are some tips on finding out things for yourself:

• key words: If you aren't sure of what key words to use, write out your question and then pick out the nouns and verbs. Using your question as an example, we have "please tell me whether I can lock a file or not". Then put them in your query after the word Perl: "Perl lock file".
• places to search:
  • Google
  • http://perl101.org/
  • Perl reference documentation
  • the search box on the upper left corner of each Perl Monks page
  • Super Search (here on Perl monks)
  • cpan module search - lets you search PerlMonks for information about a specific CPAN module
• alternate key word ideas:
  • leave out key words: especially, if on a Perl specific site, leave out the key word "Perl". Also if you are on a Perl specific site, you can try just searching for either the verb ('lock') or the noun ('file').
  • use synonyms and related topics: this requires you know something about the topic you are looking up. For example, for file locking, you could try "concurrent file access".

Best, beth