But, as I'm curious, can anyone explain why the magic <> doesn't work here?
Because <> is a synonym for <ARGV>,
and ARGV is a magic filehandle that sometimes reads from STDIN, but sometimes reads from files etc.
Dave.
| [reply]
[d/l]
[select] |
That's right... specifically, it depends on what is currently in @ARGV (if there's anything in @ARGV, the contents are treated as file names, and the files are magically opened and read from... if @ARGV is empty, it'll read from STDIN).
If the intent is to read from STDIN, then do so, explicitly, by <STDIN>. If the intent is to process files, generically, either named files or files piped through, then use <>. In the case of the original post, which seems to be (maybe) testing some external code and trying to sandbox it, somewhat, it might just be a good idea to localize @ARGV (that is, to extend the sandbox beyond just STDIN and STDOUT (why isn't he also tieing STDERR, then, though?) to include the command line).
------------
:Wq
Not an editor command: Wq
| [reply]
[d/l]
[select] |
That's right... specifically, it depends on what is currently in @ARGV (if there's anything in @ARGV, the contents are treated as file names, and the files are magically opened and read from... if @ARGV is empty, it'll read from STDIN).
As long as we're getting specific, we might as well get it exactly right: The contents of @ARGV are always "treated as file names, and the files are magically opened and read from." If @ARGV is empty, then "$ARGV[0] is set to "-", which when opened gives you standard input." - perlop
So it really never reads from the filehandle named STDIN, but it might read standard input by opening the file named "-".
| [reply] |
