in reply to Good-bye Unix filter idiom

The diamond operator, however, happily uses two-argument open to processes the contents of the @ARGV array, which by default contains the command line arguments supplied by the user. This means, that an argument "< foo" makes my program read a file named "foo", an argument "> foo" makes it clobber a file named "foo", and an argument "rm * |" makes it run a program that on my platform happens to remove every file in the current directory.

I don't get this.

You (or someone) is using a "unix filter" perl script at the command line.

You are concerned that you (or they) might accidentally (or maliciously) type a dangerous command in place of a filename as input to that script.

What is to stop you (or they) from entering that command directly into the command prompt you (or they) are using?


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^2: Good-bye Unix filter idiom
by martin (Friar) on Sep 07, 2012 at 08:40 UTC

    Quoth BrowserUk,

    I don't get this. You (or someone) is using a "unix filter" perl script at the command line. You are concerned that you (or they) might accidentally (or maliciously) type a dangerous command in place of a filename as input to that script. What is to stop you (or they) from entering that command directly into the command prompt you (or they) are using?

    The program might run with other privileges than those of the user. This is a fairly common scenario, and the "Unix-like filter program" pattern is intended to fit into it.

    Writing to standard output, e.g., is also part of the strategy to avoid overwriting arbitrary files. If the user employs redirection to write the output to a file, this file will be (or fail to be) created according to the user's privileges. Conversely, if the user just told the program where to put the output, the program would have to worry about doing this safely. This would add complexity.

Re^2: Good-bye Unix filter idiom
by Anonymous Monk on Sep 07, 2012 at 02:40 UTC

    What is to stop you (or they) from entering that command directly into the command prompt you (or they) are using?

    The danger is you can have a filename like  "rm -rf / |" so a ./foobar * ends up executing the command (and deleting files ) instead of opening that file

    A workaround is to perl -MARGV::readonly foobar *