Re^3: How to build system calls using '=>'

Why: mkpath doesn't require an external binary, doesn't create another process to do its job, and has full control over what it's doing and what comes back - there are less places that the attempt to create a directory can go wrong.

Re remembering: The link to blue_cowdawg's advice in Re: "mkdir -p" equivalent? is there specifically because it *shows* an example of how to use mkpath, including modes etc - so they don't *have* to remember.

The 17 line piece of code is an _example_. It is verbose so that the user knows where to report if they need to do so, they can always comment out the print, but it's where it is so they know if they want to report, that's *where* they should do it, i.e. it should only say it's done it once it's worked and not before.

Shelling out to 'mkdir -p $path' is OS dependent as well - if you do that on Windows (tested on xp) you will end up with a directory called "-p" as well. In the example it points out *where* to change the directory seperator.

mkdir allows you to set the mode as well, if you wish to - fair call, perhaps I could have added that in the example. :o)

Comment on Re^3: How to build system calls using '=>'

Replies are listed 'Best First'.
Re^4: How to build system calls using '=>' by Perl Mouse (Chaplain) on Dec 14, 2005 at 16:40 UTC
mkpath doesn't require an external binary Eeeck! Scary! An external binary! Code reuse! Bad! Bad! Bad! Perl is a glue language. There's nothing wrong with using a code someone else wrote. Whether that's "an external binary" (what's an "internal binary"?) or a module. doesn't create another process to do its job Yes, and? Are you worried about performance? Sure, creating another process takes a few microseconds. But we're about the muck around in the filesystem anyway. And compiling a piece of Perl isn't exactly resource free either. so they don't have to remember. Yeah, but then they have to look it up. And that takes valuable programmer time. Shelling out to 'mkdir -p $path' is OS dependent as well I never claimed it wasn't. The 17 line piece of code is an _example_. Of course. But: system 'mkdir', '-p', @dirs and die; is just one line. Even if you mimic it using 5 lines, it's still 400% more lines. Remember: programmer time is expensive! `Perl --((8:>*`	[reply]
Re^5: How to build system calls using '=>' by Anonymous Monk on Apr 17, 2009 at 16:34 UTC
Gotta agree with serf here. It's not about whether or not it's expensive or creating another process for one routine that you would want to do. It's more about practicing good programmer judgment when it comes to writing your code. Would you make system calls for everything you could (like, opening and reading in files, truncating files, moving files, parsing files) in a 3000-5000 line perl script or module you'd created? I doubt it. So why, for the love of god would you promote doing this simple routine with a system call as well. It's just poor programming practice. Serf has decidedly better points than you do about how to write this perl routine and why you would do it his way. And yes, there are several problems with using external binaries that are outside of perl to perform routines for your program. 1. Sometimes they will simply not port from one OS to another, talk about waste of valuable programmer time. You would need to re-write your code for every possible OS diference, if needed. 2. They can exercise a larger tax on system resources due to process spawning. Especially if this is the route you're going to take with large pieces of code. But, with complex pieces of code you want to be making very few system calls, if any at all. You may quickly find all of your spawned processes out of control. Lastly, while I don't promote putting in code simply for the sake of bloating your code with nonsensical information and handlers, if you're measuring your code by the number of lines of code you're producing, you're doing it wrong. You can write the same function many different ways, and while one way may take up 'less' space, it's almost certain to not have enough error handling and comments. I've never posted on Perl Monks, and I deeply appreciate all of the great folks who come out here and give freely their knowledge. But, I simply refuse to stand idly by and allow this to be the last comment on this thread as if it's the right thing to do. Peace.	[reply]


Just another Perl shrine
	PerlMonks