tags:

views:

78

answers:

3

When i try to include a file using include_once in php which shows warning like Warning: include_once(1) [function.include-once]: failed to open stream: No such file or directory in /var/www/test/content_box.php on line 2.Actually file is there in my directory.I am using ubuntu (OS) How can we prevent this warning.If anybody know please help me

+1  A: 

that's quite unusual name for the php file - a single digit 1. are you sure you have such a file?

Col. Shrapnel
+2  A: 

The proper way to prevent the warning would be to check if the first exists first and don't try to include it if it doesn't.

if (file_exists($includefile)) {
  include_once($includefile);
}

(obviously replace $includefile with the file you're including)

The quick and dirty way to do it, which I DO NOT recommend, would be to suppress the warning with the @ expression.

@include_once($includefile);

Note that when suppressing a warning this way, PHP's error handling code still runs but with PHP's error_reporting ini value temporarily changed to ignore it. As a rule of thumb this isn't a good idea because it can mask other errors.

As others have pointed out, "1" is an unusual filename for a PHP file, but I'll assume you have a specific reason for doing that.

thomasrutter
first one is subject to discuss but second one is terrible
Col. Shrapnel
Which is why I used it as an example of what not to do.
thomasrutter
looks like you just took this question too literally. that's big SO problem. everyone just answer a question, not trying to think it out a bit - what caused this question, are there other interpretations?
Col. Shrapnel
Using @ is bad. No excuses, no exceptions. if error occurs - programmer must be notified of it. NO intentional errors in the code must be left.
Col. Shrapnel
If you read my answer you would see that I am clearly explaining that using @ is not a good idea. I don't get it???
thomasrutter
Answer modified to make it even more clear that I am not recommending using @ for those who didn't read my whole answer.
thomasrutter
You don't understand what I say. Don't worry, you're not alone. there are many people who don't understand error handling :)
Col. Shrapnel
"I am clearly explaining that using @ is not a good idea." well why bother to recommend it anyway? Let me repeat: No **intentional** errors should be left in the code. Do you understand? It must be **error** to be repaired, not **error message**
Col. Shrapnel
Who are you talking to exactly? I can assure you I do understand PHP error handling. Why are you acting as if I was claiming @ to be a good idea? I never claimed that. Using @ can mask other errors in your code, which is why you shouldn't use it. I dunno maybe I'm making the mistake of feeding the trolls here. If you can tell me where you think my answer is wrong, I will fix it. If you just degrade me without pointing out the specifics, then I can't do anything.
thomasrutter
I told you it twice. 1. Your answer's lack of sense. "Do this but note that's bad thing". **why to do it then**? if it's bad anyway? 2. I am talking not of "other errors" but of this particular one. This error must be eliminated at development phase. There must be no error at all. **It is error to be repaired, not error message!** I wonder if it such hard to understand?
Col. Shrapnel
Meh I'm not going to keep fighting you. This is ridiculous.
thomasrutter
I am not a troll. I am just thinking man, unlike most people here.
Col. Shrapnel
**way to do it** heh. and now you tell me "I didn't tell to do it". Yes, it's ridiculous. You just fail to understand the logic. no wonder I looks like a troll to you :)
Col. Shrapnel
I think this may be a linguistic issue.. @Col. Shrapnel seems to have a poor grasp of English grammar.
intuited
@intuited perhaps. But I have good grasp of logic. If you think something is bad - do not recommend it at all.
Col. Shrapnel
@Col. Shrapnel: My point is that you seem to be misreading his original statement. The first four words of the phrase "The quick and dirty way to do it" are logically essential to the subsequent ones. Someone with strong English grammar skils would realize this, and would generally conclude that this was "**NOT**" a recommendation for any situation where another approach is possible. Perhaps the issue is not so much grammar as idiom comprehension. "Quick and dirty" is generally considered undesirable unless you are desperate.
intuited
@intuited So what I say - even if you desperate there are always proper solution. So, not a single reason to mention a dirty one. Especially in the given context, where not error message but error itself were asked to eliminate.
Col. Shrapnel
@Col. Shrapnel: The OP said "prevent this warning". This is ambiguous: it could mean that the goal was to resolve the issue that was creating the warning, or that it was to silence the warning itself. @thomasrutter answered both of the possible interpretations, with the caveat that silencing the warning is not a good idea. In the broader sense, there are some situations where it is useful to silence warnings, so it's good to let people know of this language feature, but important to make sure that it's not misapplied.
intuited
@intuited no, he didn't resolve the issue that was creating the warning. To resolve it, a proper filename must be set. And silencing is not an option at all, even if the OP meant it. If someone asks you how to shoot himself in a leg, it will be stupid to explain and then follow with a warning. And this case is not a situation where it is useful to silence.
Col. Shrapnel
"In the broader sense, there are some situations where it is useful to silence warnings, so it's good to let people know of this language feature, but important to make sure that it's not misapplied." For example, when you begin applying a hacksaw to your leg, a warning is issued (pain). However if you know in advance that there is an incurable case of gangrene in that leg, or that it is chained to a post in a pit containing a sleeping Vogon, then it is important to silence the warning from your nervous system, eg by using an anaesthetic. Otherwise your anguished screams may wake the Vogon.
intuited
@Col. Shrapnel: I do agree with you though that this doesn't really resolve the root issue, it just prevents a warning from being issued. In some situations (eg attempting to include an optional module/library file) the approach of checking for the presence of the include file would be appropriate. However this doesn't seem to be the case here. It sounds like you're right, that a function is being called to get the include file name and that this is being done incorrectly. We'll have to wait to see if the OP posts some code.
intuited
+2  A: 

Obviously the issue here is that PHP can't find the file you're trying to include. To reduce confusion about what the current path is, I usually make it an absolute path like this:

// inc.php is in the same directory:
include (dirname(__FILE__) . "/inc.php");

// inc.php is in a subdirectory
include (dirname(__FILE__) . "/folder/inc.php");

// inc.php is in a parent directory
include (dirname(dirname(__FILE__)) . "inc.php");

It's probably a bit over the top, but you can be sure to know where PHP is looking for your files.

nickf