Re^4: backticks and 'Cannot allocate memory'

Oh - under "normal" conditions, backticks and pwd work just fine -

main::(-e:1):   exit 0
  DB<1> x qx |pwd|
0  '/home/admin
'
  DB<2> x $?,$!
0  0
1  ''
  DB<3> q
[download]

But, in my program, I set a breakpoint to stop when cwd() returns undef. After that point, which is several hundred data files into the execution of the program, the weird behaviour is observed.

So - I'm not sure I understand all the responses here, not being much of a linux OS and forking geek. Is there a reason the believe that backticks cause memory leaks ? Is there an alternative way for Cwd::cwd to return the current path without 'pwd' ? How can I persuade it to do so, when it is used as a sub-module inside Archive::Extract which I am calling ?

Syntactic sugar causes cancer of the semicolon. --Alan Perlis

Comment on Re^4: backticks and 'Cannot allocate memory' Download Code

Replies are listed 'Best First'.
Re^5: backticks and 'Cannot allocate memory' by JavaFan (Canon) on Sep 24, 2010 at 17:54 UTC
The problem with qx is that hardly anyone checks whether it succeeds - not even people who pipe up "check the return value of open()" each time someone doesn't write 'or die' after an open command. It may very well be that the `pwd` fails because the fork fails. It's just hard to make sure by inspecting $!/$? not right after the call. Is there an alternative way for Cwd::cwd to return the current path without 'pwd' You could redefine the actual function that does the qx, and rewrite the qx using a pipe-open and an exec. Then you can examine what the open/fork returns.	[reply]

Replies are listed 'Best First'.

Re^5: backticks and 'Cannot allocate memory'
by JavaFan (Canon) on Sep 24, 2010 at 17:54 UTC

It may very well be that the `pwd` fails because the fork fails. It's just hard to make sure by inspecting $!/$? not right after the call.

Is there an alternative way for Cwd::cwd to return the current path without 'pwd'

[reply]