in reply to Re: Is there a way to open a memory file with binmode :raw?
in thread Is there a way to open a memory file with binmode :raw?

That is genius! Thank you so much for this :)

I appreciate everyone's patience with me on this over the last month or so. Digging through all the docs was informative, but just a tad overwhelming trying to piece it all together which led to confusion.

When it was pointed out that a scalar ref is NOT a file and the two are treated in different ways helped a lot.

In this round, my goal was an anonymous temp file for which I had gone on to use File::Temp which I felt was a bit heavy-handed. I'm very surprised I never came across the link you shared in my travels.

Cheers everyone,

-stevieb

  • Comment on Re^2: Is there a way to open a memory file with binmode :raw?

Replies are listed 'Best First'.
Re^3: Is there a way to open a memory file with binmode :raw? (open undef)
by tye (Sage) on Oct 13, 2015 at 04:27 UTC

    Yeah, but that way of creating temporary files doesn't even honor $ENV{TMPDIR} (at least in some configurations), which makes it one of the worst ways to make temporary files in Perl in my book. I was rather shocked when I discovered such in the Perl source code (trying to figure out why Plack temporary files were being put into the wrong directory).

    - tye        

      trying to figure out why Plack temporary files were being put into the wrong directory

      On recent linux system you can find out the original location of the deleted file by examining /proc:

      qwurx [shmem] ~> perl open $fh, "+>", undef or die "Can't create anonymous storage: $!"; $file = "/proc/$$/fd/" . fileno $fh; print "$file => ", readlink( $file ), $/; __END__ /proc/26628/fd/3 => /tmp/PerlIO_eVAtFg (deleted)

      On systems which lack /proc/$$/fd it can be quite annoying to find out, specially when the file system is full and a process is just sitting around in IOWAIT. In this condition there's a difference between disk usage of device and file system. Found that on an old Solaris server running a program which employed this trick: create file, get handle, unlink. Took me some time to find out.

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

        sudo lsof -p $PID is what I usually use. Even more likely:

        sudo lsof -p $PID | grep -vw mem

        as I usually don't care about the rather large list of shared libraries that the process has open. Also:

        sudo lsof /tmp | grep deleted

        But, yes, lacking /proc makes the job harder for lsof. I haven't worked in such an environment recently, but I seem to recall lsof being able to report paths of deleted files that are still open on systems that didn't have /proc.

        Update: But note that the question that you quoted, "trying to figure out why Plack temporary files were being put into the wrong directory", is not answered by either of these approaches. These can answer "Where is Plack putting temporary files?". I already had the answer to that because I was asking "why".

        - tye