Fork me on GitHub


Making life easier with exec

March 4, 2005 | PHP Scripting

I’ve been playing more and more with the php exec command to do stuff – I got my first taste of doing this with running htDig as a command and pulling its results into an array.

So I decided to find out if using exec to do directory listing would save any script length or not.

Well, as you can see in this file there is little difference in length and a tradeoff or two to get there.

Initially the script looks more compact and there is definitely less individual things going on. The scripts are so short though that trying to benchmark them is pretty futile.

Initially I can see on area where the old route would have the advante: file size. The php way of getting the file size needs to be computed no matter what so wether you want to write in KB, MB, or B you run no extra cycles to do so. The exec command returns KB only so if you needed to do anything different when listing the size you’re sol.

Another benefit of the php method is that the exec method is more consistent if running with a full path – not truly a big deal since you can always use $_SERVER[‘DOCUMENT_ROOT’] to help find your way around.

The exec method is a boon in that non visible files (ie: . files) are filtered by default so you don’t need to filter out hidden files or the up and down directory references and that directories are easily identified by a slash in the name instead of another call to the system to determine if the entry is a directory or a file. Yes, you could do this by looking for a file extension but with the ability to make folders with a period on the name it isn’t really truly foolproof way of making that determination.

Adding URL building capabilities is a moot point – both scripts would add the same overhead to make the entries into links.

This is far from being a conclusive test but I think the ability to interact with the shell is a wonderful thing to be able to do with PHP. It limits the scripts that are written to running on *NIX but I can live with that – I can’t see ever running on IIS and the chances of running on any other OS (ie: Solaris) is so remote that it isn’t even worth worring about.

I pondered a different application for this earlier in the day – uploading files. If the command could be handed off to a terminal command for an FTP upload then the time limit on running php scripts could be overcome for very large files. Also, when moving files after an upload the file then becomes property of the www user – this is bad since it requires a chmod or another script to run to delete the files. With an exec command the file could be moved with normal user credentials to make later deletion of the file manually easier.

Overall I can’t say that this is a conclusive test, but it certainly was a neat excercise in using php in a different way. And finding ways to interact with the system like we find ways to interact with the user will be a new way of thinking. Now I need to go perusing /usr/bin to see what I can use to make life easier.

12 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  • exec() gives another good reason to turn on safe_mode for hosting companies.. sad that many don’t. A simple php that takes user’s input and put it inside of system() or exec() can be deadly to a hosting company that doesn’t either disable system() or exec() or not turn on safe_mode. Especially on a shared hosting, it’s easy to get the MySQL db password stored on a home directory….

    Tom, March 5, 2005 9:46 am | permalink

  • Yeah, that’s why good security is needed for just about anything. Exec can be just as safe as anything else – that script is basic and contains no method of verifying any data passed to it – the base dir should be hardcoded and any other directory passed to it should be checked or expected.

    Having it available isn’t a security risk – it is how people use it that makes is a security risk. PHP in and of itself is a security risk…

    shawn, March 5, 2005 11:48 am | permalink

  • Oh, yeah, Tom, you need to allow comments on your blog… I’ve wanted to drop a comment or two but there’s not button. NO BUTTON! Augh! Or do you mean for all your questions to be rhetorical?

    shawn, March 5, 2005 11:53 am | permalink

  • ahahaah.. shawn. Got furious about my post on CSS? 🙂 The CMS is still in developing stage and I haven’t enabled comments yet. I’m working on it over the weekend..

    Tom, March 5, 2005 4:49 pm | permalink

  • oh yes. and I moved dev2 -> http://www..

    Tom, March 5, 2005 4:51 pm | permalink

  • Not furious, but had a thing or two to say 😉

    shawn, March 5, 2005 5:34 pm | permalink

  • alright shawn. You can comment now.. I got something up… it looks quite ugly… but i’ll worry about CSS tomorrow… 🙂

    Tom, March 5, 2005 9:29 pm | permalink

  • I thought you weren’t going to flame :P.

    alright, alright.. i’m adding you to the cool guy list..

    Tom, March 5, 2005 9:59 pm | permalink

  • That wasn’t a flame…

    shawn, March 5, 2005 10:04 pm | permalink

  • You wrote longer than I did.

    Tom, March 5, 2005 10:09 pm | permalink

  • There was a lot to say… I guess I just feel strongly about it since I once was similar in my coding practices. There is an easy way to do it but it just takes time and refinement to get it right.

    shawn, March 5, 2005 10:12 pm | permalink

  • Well, now that I enabled comments, I’m expecting some people I know to get furious about it. The point of the article was to get some angry CSS people. 😛

    Tom, March 5, 2005 10:16 pm | permalink

Comments are closed