Click to See Complete Forum and Search --> : PHPMan
bubblenut
03-11-2005, 05:56 PM
First off, thanks to Weed for the inspiration.
PHPMan (sourceforge PHPCLIMan 'coz someone's already taken phpman :mad: )
It's basically a command line interface for the php manual.
I'm not going to be letting people on it untill I've got something working up and running. I'm hoping to have that by the end of the weekend.
I put the idea out on #php earlier and got some good ideas, they're not going to go into the first release as that's going to be just a basic interface (sntax, long, with comments) but I'm going to put them down as feature requests.
What I've got so far
Ability to list categories
Ability to list functions within a category
GNU Info format
Use mirrors
Any more ideas?
planetsim
03-11-2005, 06:13 PM
Similar Functions maybe? similar to how PHP.net do it. Occasionally i find that useful if i foget a function name :)
bubblenut
03-11-2005, 06:22 PM
--lucky : I'm feeling lucky, like google :D
Mordecai
03-11-2005, 07:13 PM
This sounds like a great idea to me. Are you planning on using ncurses, or making the interface manually?
Also, I assume it's going to be in PHP, as well?
dalecosp
03-11-2005, 07:41 PM
This is a cool idea. I've already hacked my devel server thus:[592] Fri 11.Mar.2005 17:14:55
[kadmin@archangel][~/daleco/plans]
# phpdate
DAY =================================================
d Day of the month, 2 digits with leading zeros
D A textual representation of a day, three letters
j Day of the month without leading zeros
l A full textual representation of the day of the week
S English ordinal suffix for the day of the month, 2 characters
w Numeric representation of the day of the week
z The day of the year (starting from 0)
WEEK =================================================
W ISO-8601 week number of year, weeks starting on Monday (added in PHP 4.1.0)
MONTH ================================================
F A full textual representation of a month, such as January or March
m Numeric representation of a month, with leading zeros
M A short textual representation of a month, three letters
n Numeric representation of a month, without leading zeros
t Number of days in the given month
YEAR =================================================
L Whether it's a leap year
Y A full numeric representation of a year, 4 digits
y A two digit representation of a year
TIME =================================================
a Lowercase Ante meridiem and Post meridiem
A Uppercase Ante meridiem and Post meridiem
B Swatch Internet time
g 12-hour format of an hour without leading zeros
G 24-hour format of an hour without leading zeros
h 12-hour format of an hour with leading zeros
H 24-hour format of an hour with leading zeros
i Minutes with leading zeros
s Seconds, with leading zeros
TIMEZONE =============================================
I Whether or not the date is in daylights savings time
O Difference to Greenwich time (GMT) in hours
T Timezone setting of this machine
Z Timezone offset in seconds. Zones west of UTC are negative, east are positive.
FULL DATETIME ========================================
c ISO 8601 date (added in PHP 5)
r RFC 2822 formatted date
U Seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)DAY
==================================================So, wouldn't it mostly be a matter of getting the info into a readable format and then calling more(1) on them? Since it's on both 'Nix and NT, seems 'twould be a snap.
bubblenut
03-11-2005, 09:47 PM
Dale, yes, but I'm guessing it's going to take a little work processing the html. I've asked around and there doesn't seem to be an XML based interface. This is the single most troublesome aspect. If I write something which works off their current html design how can I safeguard it against changes in the php.net layout?
bubblenut
03-11-2005, 09:53 PM
Mordecai: I thought about ncurses and thought that might be a little complex for what I'm trying to go for. Basically, I want something with which people can get to the information they want as quickly as possible. ncurses may make the interface a little more complex than it needs to be. On the other point, yes, it's going to be completely in PHP.
I may be getting a little to far ahead of myself now but how would people handle configuration options? I'm just thinking that some people may want to work of a local copy of the manual.
dalecosp
03-12-2005, 12:47 AM
Originally posted by bubblenut
Dale, yes, but I'm guessing it's going to take a little work processing the html. I've asked around and there doesn't seem to be an XML based interface. This is the single most troublesome aspect. If I write something which works off their current html design how can I safeguard it against changes in the php.net layout? Hmm, well. I seem to have quite a gift for understatement...
Maybe I'll think about it. Of course, you can likely outthink me in a heartbeat. That may be a Good Thing(tm), lately I'm too busy to eat, even, it seems.
dalecosp
03-12-2005, 03:48 AM
originally posted by bubblenut
a little work processing the htmlYup, indeed.
I pulled down the *chm file from a mirror and used "archmage" to convert it to lil html files. Not having enough brainpower left (read: feeling exhausted, and I'm fairly dumb anyhow), I hax0red a few str_replaces together to echo the pertinent language to my xterm.
Now, a few pages (abs, for example) look good. But for the most part the HTML is pretty ugly, so no way can anything this simple(-minded) handle the task. Maybe it could if the HTML source were prettier. This may be a rather large obstacle to such an undertaking, although there are many brighter minds out there, I know. But the HTML source from the *chm files doesn't look too promising.
OTOH, the online pages are a tad cleaner, I think. My attempt at hacking a similar script for them was slightly better. However, a bunch of str_replaces aren't very pretty, and it's likely that an awake man with a good grasp of regexps could do a much better job.
I keep on wandering.... :rolleyes:
Weedpacket
03-12-2005, 05:20 AM
Originally posted by bubblenut
Dale, yes, but I'm guessing it's going to take a little work processing the html. I've asked around and there doesn't seem to be an XML based interface. Perhaps downloading the Docbook sources might be useful (far as I can tell, via CVS or cvs.php.net)?
The One Big HTML is a fright once you start delving into it.
dalecosp
03-12-2005, 11:25 AM
Originally posted by Weedpacket
Perhaps downloading the Docbook sources might be useful (far as I can tell, via CVS or cvs.php.net)? I imagine that is so. Being the ($adjective) that I am, I didn't even look for such, but wondered how in the heck they maintained the thing if it was all HTML. And, that probably explains the relatively poor state of the HTML, if it's auto-generated ... althought that doesn't sound quite right either....
bubblenut
03-12-2005, 09:25 PM
I finally found the docbook sources (after I'd written a basic html skimmer). They would be sooo nice to parse but there's a couple of issues. Firstly, you wouldn't be able to offer the user comments are these aren't held here. This could be solved by reading most of the info from the xml file and getting the comments from the html if require. Finding the relevant file would be more difficult as there is no nice www.php.net/function-name redirect thingy on cvs.php.net. Also, there does not seem to be a convenient way of looking at the most recent version of a file pn cvs.php.net as you have to enter the version number in the url. Downloading the sources could be made a requirement but that makes things more complex for the end user and there's no garuntee the sources are up to date.
I have created a pretty messy script which works off the site. It could do with a lot of tidying up and it only works for function pages but it's late and I'm tired. If people could have a quick look over it and give any comments I'd be very gratefull. I'm particularly concerned about the overall structure.
//Cut to the chase
if(!chop2substr($buff, ">$searchterm</H1\n>")) {
echo("fail 1\n");
}
This bit of code is where it jumps to the main part of the function page, if it fails then that would be where we check if it's another type of page. I can see this growing into a huge, messy, hard to follow set of if statements as more page types are added. I'm sure there's a far better way of structuring this but I just can't think at the moment.
PHP Builder
Copyright WebMediaBrands Inc. All Rights Reserved.