salathe

Not a bug, just a confused developer. I believe, like Rasmus said in your bug report, that you wanted to do an assignment by reference but what you were actually doing is a 'bitwise and' assignment. Your code tries to do: $b = $b & $this->t and because $b has not been defined before trying to be used (to the right of the =) that is the cause of the error. As stated, you probably wanted to use $b = &$this->t instead.

You want to use a solid pipe (|) rather than a broken pipe (¦).

I can't edit my post, so please note that in my code snippet any reference to "fopen" should be "file".

Another way would be to use the SPL's SplFileObject to be able to read the file easily, and a LimitIterator to start on line 34. If you're open to learning an entirely new approach (well, it's similar to the more usual fopen/fgets combo) then an example would look like: $file = new SplFileObject('networkmap.asp.htm'); // like fopen but in an OOP style $file->setFlags(SplFileObject::SKIP_EMPTY|SplFileObject::DROP_NEW_LINE); // flags like those used in fopen $limited = new LimitIterator($file, 33); // Start from 34th line (zero-based offset is 33) foreach ($limited as $value) { // $value is the same as in your original foreach }

I guess the sarcasm meter doesn't work correctly when the target is written in red letters. At the moment there are folks who have the ability to fix this typo, but since they're alumni they shouldn't be doing staff tasks (though, it happens). Unfortunately, currently, there are no active, on-staff members on board to handle even the simplest of minor, teeny, tiny things like that typo.

*salathe vaguely wonders if Ken was the first person ever to read that page (and thus notice the glaring error!)

With large data, it might be worthwhile skipping PHP entirely and going for a more streamlined approach to feeding the database with its data. My suggestion would be to use LOAD DATA INFILE (reference) which can parse your pipe-separated values (even without newline separators) directly into a table. A query would look like: LOAD DATA INFILE 'datafile.txt' INTO TABLE table_name FIELDS TERMINATED BY '|' LINES TERMINATED BY '|' (col1,col2,col3,col4,col5); That approach should be able to eat up many millions of rows without breaking a sweat.

I would probably go for something like: function add_one($match) { return $match[0] + 1; } $content = preg_replace_callback('/(?:<frame>|next:) \K\d+/', 'add_one', $content); It looks for either <frame> or next: followed by a space, then empties what has been matched so far and matches a number. That number is then passed to the add_one function and its return value is what is used to substitute the original matched number.

It is probably related to the other issues on the server. As for when/if it will get fixed, who knows. Those in charge seem to do their best to not give a hoot.

I'm too lazy to go find it, can we have a link to the thread please?

I'm guessing that's not the intention, but the OP is not being particularly clear on what they are trying to do. gibigbig, please describe clearly what you want to do as that will dictate the best solution for you. For example, do you have a whole HTML page containing some links and you want to get the 4shared.com URLs out of that HTML? Do you want to match any link, or just that one link, or...?

~http://www\.4shared\.com/embed/261987034/3ce33fcf~

The irony is, the person who moved it is not a member of staff.

Sure, perhaps even more often and for longer periods.

What else just happened the last 5 hours?

Absolutely do not quit your job just because they're using CakePHP! If you are worried about forgetting details in "core PHP" then there are plenty of hours outside of work (and likely lots inside of work) where you can keep track of, or learn, these "core" ideas. Out of interest, what you were expecting: everything to be done without a framework or using a homebrewed framework or..?

Ouch. Looks like someone needs to install some software to prevent this kind of thing happening again. Apache having a fit can happen at any time and it would be best if a recovery was automated (there are tools to do this) or at least have someone(s) notified quickly of problems who can come and give it a kick. 24 hours of downtime is ridiculous in this day and age! P.S. Good to see the site back up, however.

Great work guys with those latest couple of posts, you've covered key points that I was going to mention. However, I'd still like to jump on a few other notes and possibly touch on what you've already discussed. Harking back to post #9, the following pattern was offered: ~^\A.*[;]$~U When using regular expressions in PHP there are often many ways to do the same thing. Different ways are not necessarily wrong or right, so long as they get the job done! There are a number of 'special' characters to be considered when writing our patterns and indeed the context in which characters are placed can give them different meanings. As an example, the dot character (.) is generally used to match "anything except a newline character". This meaning is not true within a character class ([.]) yet oftentimes there is the tendancy to, absolutely needlessly, escape the dot (which outside of a character class would cause it to lose any special meaning and simply match a dot) within character classes ([\.]). A similar situation has occurred (unless I'm mistaken) with the \A of premiso's regex. I believe he was attempting to match a literal capital A character yet, whether it was a typo of deliberate escaping, did not do so. See \A is one of the magical, mystical special sequences of characters: it matches the very start of the subject string (like ^ when not using the multiline pattern modifier). To this end, the first part of the regex (^\A) is effectively doing the same thing twice: making sure that we're currently at the start of the subject string. Happily, the following .* allowed any starting letter A to get matched to make it appear that the regex was doing what it was intended to do. Note however, that it will also match "Oops;" which was not intended. The next part of that regex is [;]. The semicolon was enclosed in square brackets because, by his own admission, premiso was not sure whether it is a special character. It does not have any special meaning, anywhere. So that's one regex down and a lot of waffle for a 12-character pattern. The later patterns have been covered very well in the previous couple of posts. The key points being that the parentheses around the later regex were not necessary since a) the entire match can always be referenced with $0 or \0 in the replacement string, and b) we did not want to use the matched text anyway. As cags put forward, it would also have been a good idea to use something like [^}]* in place of .*—it is good practice to try to be as explicit as possible with regards to what you want to match (in this case, declaring precisely what we don't want to match). This would have helped with the issue of matching too much (it simply would not have happened) and the changes to the pattern as a result of that. Whilst on the subject of being as specific as possible, those ^ and $ at the start and end of the regex could have been put to good use. Aside from matching the very beginning and very end* of the entire subject string, they can be used to match the start and end of any line within the subject by using the m modifier. This would have been useful to, for example, make sure that the closing brace (}) was on a line of its own (e.g. …^}$) or to make sure that the CSS selector was at the start of a line (^\.sideAds…). Also note that \A could have been used to make sure the select was at the very beginning of the subject string (\A\.sideAds…). That's enough; you're probably bored by now! To lighten the mood, here's an animated badger: (did your eyes skip here before reading everything?.. get back to reading!) * I've posted about this before by, by default, the $ character will match the very end of the string or immediately before a trailing newline character (in other words /cake$/ will match "cake" when given the string "pancake\n"). To not allow matching if there is a trailing newline, use the D pattern modifier ala. /cake$/D—this has obvious repercussions if the $ is being used in multiline mode.

There are numerous tools that you can use to coerce HTML into well-formed HTML or XML (the latter being most useful to you); one such tool is HTML Tidy.

It will probably be helpful to take a peek at pack (likely using H* or h* depending on the 'hex encoded format').

You can use alternation to look through a whole bunch of values. For example: /\b(?:cat|dog|hamster|horse|badger|mushroom|snake)\b/i

sangoku, can you describe more thoroughly what you want? The details are important for offering a solution. If the aim is to "explode" into an array, you could use one way; to "explode" into a space-separated string you would use a different way. So, please describe as best you can what you want to get from the string. [ot]Edit: I hadn't even posted before oni-kun edited with "Salathe, back off :-\" I wasn't going to comment on oni-kun's post anyway![/ot]

sh0wtym3, if you are still needing help please let us know. premiso's posts contain a number of errors and falsehoods which might distract your learning about regular expressions. I'd go through everything but a) nobody likes a smart-arse, and b) I'm supposed to be working.

The method that you discovered would probably be what anyone else would suggest. Care to elaborate on your method, and any shortcomings or faults with it that you've noticed (for instance, needing well-formed XML).