Essentially I'm making a PHP script using php, but I can't define variables.
If I try:
It won't work... I think I've tried just about everything.Code:$phpcode .= "html_entity_decode("$")myvar = \"test\"";
Any ideas?
Printable View
Essentially I'm making a PHP script using php, but I can't define variables.
If I try:
It won't work... I think I've tried just about everything.Code:$phpcode .= "html_entity_decode("$")myvar = \"test\"";
Any ideas?
Stupid question:
how about this?Code:$phpcode .= "\$myvar = \"test\"";
I'd think there are some problems with using a function within quotes like that.
Usually, I'd go with:
func(...)."something"
etc.
The dollar sign is by default slashed, I believe, within a thread, to prevent problems. There is likely a way around this.
Are you later using the eval() function?
If you can tell us the purpose, we can figure it out more. From what you posted, I truly see no point in it... just type the literal line. But there must be some reason beyond that for using it.
Haha... you know what else is stupid ItsMeOnly? That your stupid solution doesn't work.
In my opinoin no real question is stupid (as long as it is an actual question and not a spammer trying to make posts). I'm not sure what it is you are trying to accomplish here. Maybe some more insite would help.
I actually have the problem solved now. I stored the "$" sign in a variable and called it later. Using it outside the string keeps it from being read as a variable which already exists. If said variable doesn't exist it will appear blank, and that was the error I was getting.
Well, because PHP automatically parses anything in double quotes(" & "), you need to use single quotes.
PHP Code:$some_value = 'some random string';
$php_code = '$some_var = "'.$some_value.'"';
Point taken, thanks Brady. This is what I did though:
Code:$dsign = "$";
$phpcode = $dsign."query = \"mysql query...\"";
That works, or the single quote solution is easy.
Also, ItsMeOnly's phrasing wasn't great, but it wasn't an insult to you. He meant HIS question was stupid (asking if it would work), not that yours was.
I must say that, as is usual with eval(), there's probably a better way to accomplish whatever it is you're trying to do.
I agree, and I'd like to know what is to be accomplished to see if there's a better workaround.
Just a random note-- to set a variably-named variable, use this:
$name = 'myvarname';
$$name = 'myvarvalue';
echo $myvarname;
//returns 'myvarvalue'
(The $$ must be used, not $some$thing, or you'll get errors.)
Variable variables are almost as ugly as eval(). An associative array would be preferable by far.
I have come across a situation in PHP that required code to be generated. I maintain an extension for a CMS that will show the user a screen to help them change values in a config file. As with a lot of PHP programs the config file was written in PHP. So it was necessary to generate PHP code.
Okay, I'll explain my situation, but it's a long one.
Every time I delete a user off my MySql db via admin control panel, the ID auto_increment would skip.
Example if I had users
1
2
3
4
5
6
7
and decided to delete 6, the next user's id would be added as "8" and not "7". So I gather the current db content, convert to a php script, write it to a file and run the file. I first DROP TABLE users, then reset all the content. It works well now though, so I guess the discussion doesn't really need to be carried on any more. I hope this expains my situation more.
I'm not clear on why you would need to use anything this complex.
Just run through each result of the query for SELECT * FROM.... ORDER BY ID
Then with each set the number to $n, then $n++;
...you're done.
I also would be quite wary of a script that actually deletes the entire user list, only to replace it a minute later. What if the page gets corrupted while loading? Oops...?
Easier still, you can just drop the column then add it again.
Hmm... but you would you be able to force order by to the original order? Maybe this would be the default. That's the only catch I see there.
The order is preserved even without a primary key. That's the nature of MySQL (and, indeed, most relational databases).