I wonder if you understand that highligh_file() *is* a call to the *same* function that provides .phps files with functionality. By adding line numbers to this function, we are automatically adding them to .phps free of charge. Doesn't break anything or make anything less secure.
The only security implications of .phps are user related and are also inherent in files shown with highlight_file. I *really* have no clue about why you say it's half broken. It works fine (except for that extra line number thing, but that's no real problem I'm sure -- the extra line number is also *not* evident in files highlighted by highlight_file() as I don't think you understood) and, if it is not supported by your host, a simple call to highlight_file() is the *exact same thing*. Nowhere in my code is there a regex. I mean, use highlight_file or .phps or whatever, you're advocating the use of the *exact same functions* in the end. They all eventually break down to zend_highlight(). Devon Yasuo Ohgaki wrote: > I prefer not to add any more feature to phps. The functoinality > should be provided within hilight_file/stirng/etc to avoid needless > complexity if it is needed. > > I've been pointed out reasons why we are better to use > functions instead of phps in bug db and/or list sevral times. > In short, we are better to use show_source() for better security > and management of output. > > I'm not against having line numbers, but just against adding > anymore features to phps. (It's half broken and we don't know > when it became fully functional also) > > But this can be done by a simple regex and loop can add line number > can't be? > > hilight file > slipt text by line ending char > loop though the array > add line number > output the result > > We can do that in PHP or in Scripting. We don't need better > performance for these IMHO. > > Make sense? > > -- > Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php