in reply to Re: backticks and 'Cannot allocate memory'
in thread backticks and 'Cannot allocate memory'

Here is what I get in $?: 
  DB<5> x $?,$!
0  '-1'
1  'Cannot allocate memory'

  DB<6> x qx|pwd|
  empty array

  DB<7> x $?, $!
0  '-1'
1  'Cannot allocate memory'

[download]
Memory utilization (ps -auxf):
admin 5033 6.3 61.4 1301804 1251316 pts/1 S+ 16:56 2:17 | \_ perl -d Program-name

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

Replies are listed 'Best First'.
Re^3: backticks and 'Cannot allocate memory'
by JavaFan (Canon) on Sep 24, 2010 at 09:37 UTC
    $! being 1 is probably just a default value. I get $! to be 1 as well, but it means something differently: 
      DB<1> x $?, $!                                                      
+          
0  0
1  'Illegal seek'

    [download]
    However, my pwd does succeed. It still leaves $! to be 1, but it's string value changes: 
      DB<2> x qx|pwd|                                                     
+          
0  '/tmp
'
  DB<3> x $?, $!                                                      
+          
0  0
1  ''

    [download]
    It's curious to see your pwd fails. Is that from a debugging session where you aren't doing anything else? What happens if you use the fully qualified name to pwd? Anyway, the external pwd failing isn't something that happens on the perl level.
[reply]
[d/l]
[select]
      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

[reply]
[d/l]
        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]

In Section Seekers of Perl Wisdom