in reply to Inserting a file inside of another

Regarding the first point, if you were actually interested in tool that can both insert and replace, I would suggest 

cp_range in_file out_file [ in_spec [out_spec] ]

   in_spec: [in_start],[in_length]
       in_start defaults to 0
       in_length defaults to -1 (rest of file)

   out_spec: [out_start],[in_length]
       out_start defaults to end of file
       out_length defaults to -1 (rest of file)

   Negative values for *_start and *_length behave as per substr.

[download]

Replies are listed 'Best First'.
Re^2: Inserting a file inside of another
by BrowserUk (Patriarch) on Feb 20, 2010 at 09:28 UTC

    Could you spell out your objection(s) to the use of bareword file handles, at the top level scope of 20 line stand alone script. Beyond "needless"?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      If this is just a short throw-away script, there really is no problem with your file handles. However, I do not use them even on small scripts for several reasons.

      First, it is good to get in the habit of using variables for file handles; they will stand you in good stead when you start writing larger and more complex programs.

      Over time a small script may not stay small. The script may just need a slight modification to do something more, and then just another tiny improvement ...

      Finally, I like to reuse code I've already written wherever I can. So small snippets of code tend to get plugged into larger scripts (where it makes sends to do so.)

[reply]

      It's hard to prove a negative (that's it's not needed). Perhaps you could offer a counter example (an example that it is needed) that would disprove what I said? I can't come up with any.

      Update: I misread, or rather forgot what I read by the time I composed my answer. (Still sleepy.)

      I'm sure I don't need to tell you the issues regarding the use of global variables, so perhaps you are suggesting small scripts should use global variables. I wouldn't mind if you explained that, because I don't follow your line of reasoning either.

      Given two possibilities, one that could give you problems, and one equally simple and clear but without the baggage, why would you pick the former?

[reply]
        I don't follow your line of reasoning either

        Essentially, I don't mind one way or the other within the main of (especially short) scripts.

        That is, I fully appreciate the necessity for modules to localise (whether through local or lexicals), their affects upon the global environment. The global environment is the property of the top-level script.

        But at the top-level of a script, I think it is a matter of choice, and do not see the need to dictate it one way or the other. If it was that imperative, then we'd also have to re-open STDIN, STDOUT STDERR, ARGV etc. to lexicals in every script, but we don't.

        As for my preference, I prefer BAREWORDS for IO entities, because I think it serves to highlight an important distinction. That of things which have far-reaching (global) side-effects, and those that do not. I find the prevalence of the desire to make these two quite different things all look the same regretable.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom