in reply to "mkdir -p" equivalent?

In such cases, I tend to use: 
    system mkdir => '-p' => @dirs;

[download]

After all, that's why we have a Unix toolkit - it's not a shame to use it.

And yeah, I know that doesn't work on Windows. But I said that I tend to use it, and I don't do Windows. ;-). (But if I do, I install cygwin, and I've a Unix toolkit).

Abigail

Replies are listed 'Best First'.
Re: Re: "mkdir -p" equivalent?
by ccarden (Monk) on Aug 05, 2003 at 22:55 UTC
    Ahh, but here is the real problem: certain customers forbid us from changing the platform load. Has anyone else run into this? It's very common with many of the projects that I have worked on in the Detroit area.

    Security and system administration are very, very tight at the auto companies. Everything must be served, and if I want to use cygwin, I'd have to jump through hoops to serve it along with the desired version of perl. Btw, perl is frowned upon quite seriously at the autos. The patent response from certain admins is: "Who's going to support it? If it breaks, who do I call, the Internet? Ha. Ha. Ha."

    Geez, Louise.

    So, for now, the answer is that we keep one server at the back end of our system that runs all of our perl scripts. This allows us to use perl without running into too many complaints. But the server could easily change from *nix to win32 in a year. So my code needs to be able to run if such a change occurs.

    Thanks to everyone for the valuable input.

    -- ccarden

[reply]
      And did you tell them you can buy commercial support for Perl?

      Also, ask them in which language they like there server-side programs to be run in? Python and PHP suffer the same "problems" as Perl. If it's written in C, changing from Unix to Windows won't be trivial. Which leaves Java?

      Abigail

[reply]
        This is a very touchy subject. It has taken me years to learn how to dance around customers' internal issues. I wish I had known a lot of this 15 years ago. In fact, it would be great if university IT programs offered a class in real-world issues such as:
        • consultant diplomacy
        • valuation of your skill-set against salaries
        • salary negotiation

        Yes, I did mention commercial support for Perl, but the largest customer's admin services provider said that they are not interested in supporting yet another tool if it is only used in a few odd cases (debatable). They expect the software vendor to support such tools.

        If we write a solution that uses Apache for some reason (e.g., suExec), then we must support Apache. In order for us to do this project with Perl and Linux we had to put it all on some back-end workstations that will be supported by an admin consultant.

        Perl and Python are gaining some de facto acceptance in these larger companies, but they still require a lot of work to get approved.

        Intended as humorous or not, you are correct: Java is the only widely accepted portable language, among the autos here in metro-Detroit. We are using a combination of Perl, jsp, and a little xml (awesome for creating and parsing config files!) to get the job done in our current project. But Java can be a pig at times, so I try to do the bulk of the grunt work in Perl.

[reply]

In Section Seekers of Perl Wisdom